Skip to content

SR-1005: [Foundation] Replace posix_spawn by NSTask #303

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 8 commits into from

Conversation

Bouke
Copy link
Contributor

@Bouke Bouke commented May 2, 2016

Currently this cannot be merged as builds fail on Linux;

@mxcl
Copy link
Contributor

mxcl commented May 2, 2016

@swift-ci Please test

@Bouke Bouke changed the title [Foundation] Replace posix_spawn by NSTask SR-1005: [Foundation] Replace posix_spawn by NSTask May 6, 2016
@Bouke
Copy link
Contributor Author

Bouke commented May 6, 2016

The failing OS X build doesn't appear to be related. Regarding the failing Linux build, this PR is dependent on a change in Foundation (PR).

@Bouke
Copy link
Contributor Author

Bouke commented May 7, 2016

When testing this on Linux, most build-related tests fail. What I've found so far is that Process.arguments contained the absolute path of the test suite. However after my patch, it somehow only contains the filename, not the path. As Process.arguments is used to infer the build directory, this fails as it is assumed to be in the CWD. For example see: swiftBuildPath.

BEFORE:

Process.arguments: 
["<builddir>/Ninja-ReleaseAssert/swiftpm-linux-x86_64/debug/SwiftPMTests.xctest"]

swiftBuildPath: 
"<builddir>/Ninja-ReleaseAssert/swiftpm-linux-x86_64/debug/swift-build"

AFTER:

Process.arguments: 
["SwiftPMTests.xctest"]

swiftBuildPath: 
"<sourcedir>/swiftpm/swift-build"

@Bouke Bouke force-pushed the sr-1005-nstask branch from 107c7fd to f4769e6 Compare May 9, 2016 07:34
Bouke added 6 commits May 10, 2016 23:57
NSTask does not run inside a shell, so no automatic PATH
lookups are performed for binaries. Also referencing binaries
by an absolute path is not desirable, so for relative paths
a shell is opened and the absolute path is looked up through
`which`.
No memoization has a performance penalty of ~6%.
Previous implementation used a temporary file, however
NSTask doesn't allow child process to access parent's file
descriptors. So stdout is used to communicate the toml
output.

See also: http://www.cocoabuilder.com/archive/cocoa/292758-sharing-file-descriptors-to-an-nstask.html
@Bouke Bouke force-pushed the sr-1005-nstask branch from f4769e6 to 67477b8 Compare May 10, 2016 22:16
@Bouke
Copy link
Contributor Author

Bouke commented May 10, 2016

I've rebased the PR and tested against OSX and Ubuntu. Please retest.


var environment = environment
#if Xcode
let keys = ["SWIFT_EXEC", "HOME", "PATH"]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This lost the change to add: "TOOLCHAINS", here that I made in the past couple of days.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I missed that, I've restored those changes.


private var memoized = [String: String]()
private let PATH = [POSIX.getcwd()] + (getenv("PATH") ?? "").components(separatedBy: ":")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We shouldn't default to looking in the cwd, that can be a security issue.

@ddunbar
Copy link
Contributor

ddunbar commented May 16, 2016

I'm closing this out... per my email to swift-build-dev I'm not longer convinced we should try to move all of our infrastructure onto the Foundation APIs. I think instead we should do it on a case by case basis, and in this case (posix_spawn) my feeling is that our needs match using the POSIX API directly, and I am fine with us needing to maintain the infrastructure for that (at least until there is a standard POSIX module for Swift itself).

I think some of the cleanups on this branch make sense, but it didn't look like I could easily cherry pick them out.

@ddunbar ddunbar closed this May 16, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants