[swift-corelibs-dev] Proposal: Make NSTask's standardInput/standardOutput/standardError properties type-safe

2015-12-17 Thread Dan Stenmark via swift-corelibs-dev 
This is my first proposal to swift-corelibs, so I’m not sure how much 
flexibility we have in terms of deviating from the darwin’s original Foundation 
definitions.  That said, it’s always seemed a little screwy to me that NSTask's 
standardInput/standardOutput/standardError properties sacrifice any semblance 
of compile-time type safety by accepting id/AnyObject (which, at run time, must 
be either NSPipe or NSFileHandle, else it blows up).  If allowed, I’d like to 
take the opportunity to modernize this in the open source version of Foundation.

public class NSTask : NSObject {

...

public enum IOType {

case FileHandle(NSFileHandle)
case Pipe(NSPipe)
}

public var standardInput: NSTask.IOType?
public var standardOutput: NSTask.IOType?
public var standardError: NSTask.IOType?

...

   
}

Dan___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Proposal: Make NSTask's standardInput/standardOutput/standardError properties type-safe

2015-12-17 Thread Dan Stenmark via swift-corelibs-dev 
Hi Tony, thanks for the response!

In regards to why an enum w/ associated values:

- It avoids creating additional storage.  (Admittedly, a very small amount, but 
the point still stands.)
- It deterministically defines that it’s either one or the other, and guards 
against someone trying to be clever and setting both the Pipe and Handle 
properties.  Even if we do have a safeguard for that (like “setting the Pipe 
property nils out the File Handle property” and vice-versa), making it a 
type-safe enum improves API clarity.  I’m generally not a fan of implicit API 
behaviors that require reading the fine print, and while they are necessary 
sometimes, I’d much prefer the class’s declaration makes it clear from the 
get-go.  
- Furthermore on the previous point, it helps encourage safer client usage 
patterns for callers getting pre-launched NSTask objects from opaque factory 
methods.  (I don’t see this pattern out in the wild very much, but I don’t want 
to rule it out, especially if Swift starts taking off on the server-side).

Dan

> On Dec 17, 2015, at 12:31 PM, Tony Parker  wrote:
> 
> Hi Dan,
> 
> Thank you for your proposal. This is the right place to start discussion of 
> it. If we want to do this then we would have to make changes in both Darwin 
> and open source versions, to maintain source compatibility.
> 
> Out of curiosity, why propose an enum instead of an additional set of typed 
> properties? Looking at the implementation of NSTask, it sure seems like we 
> only expect either a file handle or pipe. I’m not sure if we would ever add 
> another.
> 
> - Tony
> 
>> On Dec 17, 2015, at 11:34 AM, Dan Stenmark via swift-corelibs-dev 
>> mailto:[email protected]>> wrote:
>> 
>> This is my first proposal to swift-corelibs, so I’m not sure how much 
>> flexibility we have in terms of deviating from the darwin’s original 
>> Foundation definitions.  That said, it’s always seemed a little screwy to me 
>> that NSTask's standardInput/standardOutput/standardError properties 
>> sacrifice any semblance of compile-time type safety by accepting 
>> id/AnyObject (which, at run time, must be either NSPipe or NSFileHandle, 
>> else it blows up).  If allowed, I’d like to take the opportunity to 
>> modernize this in the open source version of Foundation.
>> 
>> public class NSTask : NSObject {
>> 
>> ...
>> 
>> public enum IOType {
>> 
>> case FileHandle(NSFileHandle)
>> case Pipe(NSPipe)
>> }
>> 
>> public var standardInput: NSTask.IOType?
>> public var standardOutput: NSTask.IOType?
>> public var standardError: NSTask.IOType?
>> 
>> ...
>> 
>>
>> }
>> 
>> Dan
>> 
>> ___
>> swift-corelibs-dev mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Recommended posix_spawnattr_t for NSTask's implementation

2015-12-18 Thread Dan Stenmark via swift-corelibs-dev 
I hope to take a crack at implementing some of NSTask this weekend.  What are 
the recommended posix_spawnattr_t flags that should be set?  Do we also want to 
take the opportunity to expose the ability to override some of these flags 
(like POSIX_SPAWN_SETPGROUP) or do we want to avoid tying this with 
posix_spawn() too closely?

Dan
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Recommended posix_spawnattr_t for NSTask's implementation

2015-12-18 Thread Dan Stenmark via swift-corelibs-dev 
I’m assuming that OS X’s method for setting a pthread’s cwd is private API.  
Unless a better way to accomplish the same end-goal is in the works, is there 
any way to expose it?

In regards to Linux, the more I look at this, the less attractive posix_spawn() 
appears as a way of implementing this on that platform.  I’ll likely have a 
better idea how to approach this following some prototyping later tonight, but 
my current line of thinking involves vfork() -> unshare() -> chdir() -> 
execve().

Dan

> On Dec 18, 2015, at 12:39 PM, Pierre Habouzit  wrote:
> 
> FWIW Glibc implements posix_spawn on posix platforms in terms of {,v}fork + 
> execve.
> So that means that SIGCHLD can be used.
> 
> I don’t think linux has per-thread wd, since linux has had atcalls for a very 
> long time, which makes this system interface not useful and only weird 
> (pthread_{,f}chdir).
> 
> I don’t think there’s a good way to fix this beside asking for POSIX to have 
> a posix_spawnattr_setwd(attr, const char *); or changing it around the spawn, 
> which of course, is bad and racy
> 
> The other alternative is to use a trampoline execv() when -[NSTask 
> currentDirectoryPath] has been set that will just chdir() and exec's again. 
> it’s not really pretty but does the job. Given that this should be the 
> exception and not the rule, maybe that’s acceptable.
> 
> 
> -Pierre
> 
>> On Dec 18, 2015, at 11:37 AM, David Smith via swift-corelibs-dev 
>>  wrote:
>> 
>> One issue that we ran into in the ObjC NSTask is setting the current working 
>> directory in the child process. We worked around the lack of an API for that 
>> by using per-thread working directories, which is kind of awful. I'm not up 
>> to date on what the best approach to use for this on Linux would be; it 
>> sounds like clone() can do it, but I don't know if that's exposed at the 
>> posix_spawn level at all.
>> 
>>  David
>> 
>>> On Dec 18, 2015, at 11:08 AM, Dan Stenmark via swift-corelibs-dev 
>>>  wrote:
>>> 
>>> I hope to take a crack at implementing some of NSTask this weekend.  What 
>>> are the recommended posix_spawnattr_t flags that should be set?  Do we also 
>>> want to take the opportunity to expose the ability to override some of 
>>> these flags (like POSIX_SPAWN_SETPGROUP) or do we want to avoid tying this 
>>> with posix_spawn() too closely?
>>> 
>>> Dan
>>> ___
>>> swift-corelibs-dev mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
>> 
>> ___
>> swift-corelibs-dev mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

[swift-corelibs-dev] Defining _GNU_SOURCE for module-map-included headers

2015-12-20 Thread Dan Stenmark via swift-corelibs-dev 
I'm trying to invoke Linux's unshare() system call from Swift, but without much 
success.  From C, it requires _GNU_SOURCE to be #define'd before the #include 
.  The Glibc module map does indeed include sched.h, so the lack of 
_GNU_SOURCE appears to be the likely culprit.  What's the appropriate action to 
take here?

Dan
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSTask and NSFileHandle implementation

2016-04-16 Thread Dan Stenmark via swift-corelibs-dev 
Hey Alexander,

I supplied most of the initial implementation of NSTask, but was holding off on 
IO redirection until someone tackled NSFileHandle.  I can’t say if anyone else 
on this list is working on this right now, but if not and if you’re really 
interested in finishing NSFileHandle, I would (very happily!) take care of the 
relevant implementation in NSTask.

Dan

> On Apr 16, 2016, at 1:50 AM, Alexander Alemayhu via swift-corelibs-dev 
>  wrote:
> 
> Hei Everyone,
> 
> Is anyone working on the NSTask and/or NSFileHandle implementation? 
> 
> I would like to fix the hangs issue in order to revert [3aa8434][0](disable
> NSTask tests for now since it can cause hangs., 2016-01-21), but want to avoid
> duplicating work. Fixing this should also resolve [SR-625][1].
> 
> Thanks.
> 
> [0]: 
> https://github.com/apple/swift-corelibs-foundation/commit/3aa8434df50d9513a0ac1646fb52516a092fa728
>  
> 
> [1]: https://bugs.swift.org/browse/SR-625 
> 
> 
> -- 
> Mit freundlichen Grüßen
> 
> Alexander Alemayhu
> ___
> swift-corelibs-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] NSTask and NSFileHandle implementation

2016-04-16 Thread Dan Stenmark via swift-corelibs-dev 
While we’re on the subject, I’ve been out of the loop for a little while: how’s 
the Linux-side implementation of dispatch sources looking these days?  In 
particular, I’m interested in the status of DISPATCH_SOURCE_TYPE_READ and 
DISPATCH_SOURCE_TYPE_PROC.

Right now, NSTask is using Good Ol’ CFRunLoops for it’s event handling, and I’d 
really like to move that over to GCD as soon as I can.

Dan


> On Apr 16, 2016, at 1:55 PM, Dan Stenmark  wrote:
> 
> Hey Alexander,
> 
> I supplied most of the initial implementation of NSTask, but was holding off 
> on IO redirection until someone tackled NSFileHandle.  I can’t say if anyone 
> else on this list is working on this right now, but if not and if you’re 
> really interested in finishing NSFileHandle, I would (very happily!) take 
> care of the relevant implementation in NSTask.
> 
> Dan
> 
>> On Apr 16, 2016, at 1:50 AM, Alexander Alemayhu via swift-corelibs-dev 
>> mailto:[email protected]>> wrote:
>> 
>> Hei Everyone,
>> 
>> Is anyone working on the NSTask and/or NSFileHandle implementation? 
>> 
>> I would like to fix the hangs issue in order to revert [3aa8434][0](disable
>> NSTask tests for now since it can cause hangs., 2016-01-21), but want to 
>> avoid
>> duplicating work. Fixing this should also resolve [SR-625][1].
>> 
>> Thanks.
>> 
>> [0]: 
>> https://github.com/apple/swift-corelibs-foundation/commit/3aa8434df50d9513a0ac1646fb52516a092fa728
>>  
>> 
>> [1]: https://bugs.swift.org/browse/SR-625 
>> 
>> 
>> -- 
>> Mit freundlichen Grüßen
>> 
>> Alexander Alemayhu
>> ___
>> swift-corelibs-dev mailing list
>> [email protected] 
>> https://lists.swift.org/mailman/listinfo/swift-corelibs-dev
> 

___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev

Re: [swift-corelibs-dev] Wrapping up Swift 3 for swift-corelibs

2016-07-28 Thread Dan Stenmark via swift-corelibs-dev 
> 1. Integrate swift-corelibs-dispatch into Foundation.

Are there any lingering items in swift-corelibs-dispatch that are still pending 
full implementations on either Darwin or Linux?

Dan
___
swift-corelibs-dev mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev