Skip to content
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

process and pipe cleanup #12739

Merged
merged 15 commits into from
Aug 26, 2015
Merged

process and pipe cleanup #12739

merged 15 commits into from
Aug 26, 2015

Conversation

vtjnash
Copy link
Member

@vtjnash vtjnash commented Aug 21, 2015

this is a grab-bag of various fixes to the Process and Pipe handling. I'm sticking all of these together to try to minimize the incremental API churn and breakage:

@vtjnash vtjnash added the breaking This change will break code label Aug 21, 2015
iswritable(::DevNullStream) = true
isopen(::DevNullStream) = true
read{T<:DevNullStream}(::T, args...) = throw(EOFErorr())
write{T<:DevNullStream}(::T, args...) = 0
Copy link
Member

Choose a reason for hiding this comment

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

This might be ok for now but I'm not sure it's right. Semantically, I believe all bytes are successfully written to DevNull.

Copy link
Member Author

Choose a reason for hiding this comment

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

i think you're right, i just don't know if there is a good way to generically compute the number of bytes that got "written"

Copy link
Member

Choose a reason for hiding this comment

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

That's what sizeof is for.

@JeffBezanson
Copy link
Member

Awesome!! Looks really good.

Very happy to see jl_alloca go away. Do any packages use it? Would be best to remove it entirely.

It looks like the fix for #12176 can be split out? Maybe the DevNull changes too?

@JeffBezanson
Copy link
Member

Also, I'm pretty sure you meant this replaces #11919, not #12113?

@vtjnash
Copy link
Member Author

vtjnash commented Aug 21, 2015

Also, I'm pretty sure you meant this replaces #11919, not # 12113?

fixed. i have no idea how that got into my paste buffer

It looks like the fix for #12176 can be split out? Maybe the DevNull changes too?

yes they could. i put them all together here mostly to see if there would be any overlapping API decisions. i generally try to structure many of my commits so that they are relatively independent and could be reordered or dropped as needed.

Very happy to see jl_alloca go away. Do any packages use it? Would be best to remove it entirely.

I'm not sure, so the deprecation should happen in a separate PR.

@JeffBezanson
Copy link
Member

Looks like a small memory leak can only happen if link_pipe fails? In that case, would it make sense to put link_pipe inside the try-finally block in spawn?

@JeffBezanson JeffBezanson added this to the 0.4.0 milestone Aug 21, 2015
@vtjnash
Copy link
Member Author

vtjnash commented Aug 21, 2015

to do it right, you would need to figure out how far into setting up stdio it got and then unwind those steps (starting at https://github.com/JuliaLang/julia/pull/12739/files#diff-ab46297895850308343e9cbd5ebeb6cdR392). it would be a good improvement (the old code didn't do it either)

PipeEndpoint has behavioral flaws when used on its own since it is incapable of tracking the full pipe and the behavior of both ends
…2):typemax(UInt32) that may be returned by spawn on windows (fixes #12176)
@sbromberger
Copy link
Contributor

Thank you for including #12050.

@IainNZ
Copy link
Member

IainNZ commented Aug 23, 2015

Very happy to see jl_alloca go away. Do any packages use it? Would be best to remove it entirely.

https://github.com/search?l=julia&q=jl_alloca&type=Code&utf8=%E2%9C%93

Looks like no, except for various forks of Julia

@ViralBShah
Copy link
Member

Is this good to merge now? Looks like the last major thing in the way for 0.4 RCs.

@vtjnash
Copy link
Member Author

vtjnash commented Aug 25, 2015

yes. however, since this is breaking for the definition of open(cmd), i was thinking of merging this as close to the branch point as possible, so that writing the deprecation in packages is a simpler test >v"0.4.0-dev"

@StefanKarpinski
Copy link
Member

That is literally the worst reason to delay merging something I've ever heard.

@ivarne
Copy link
Member

ivarne commented Aug 25, 2015

That is literally the worst reason to delay merging something I've ever heard.

+1

@vtjnash
Copy link
Member Author

vtjnash commented Aug 25, 2015

That's my deadline for hitting the merge button. I won't hinder anyone else from merging it sooner.

@ViralBShah
Copy link
Member

Please merge. We are pretty close to the branch point.

@StefanKarpinski
Copy link
Member

@JeffBezanson, please merge if you're happy with this.

@JeffBezanson
Copy link
Member

My main concern is that the change to open has not really been discussed at all. All we wanted was to make it easier to read stderr, and I don't think changing open is necessary to do that. (There are also bug fixes applicable to master bundled in here, which annoys me extremely, but that's a much smaller issue right now.)

@vtjnash vtjnash removed the breaking This change will break code label Aug 25, 2015
@vtjnash
Copy link
Member Author

vtjnash commented Aug 25, 2015

agreed, i've taken out the change to open in a separate revert commit so that this PR is no longer breaking and can be be merged once CI passes. Later, I'll open a second PR to revert that last commit, with more focused discussion. Including it here was initially helpful since it helped me test out these changes and account for the overlapping functionality, but the actual change doesn't need to happen in this PR merge.

for separation into a independent merge commit
@JeffBezanson
Copy link
Member

That's great; then we can merge this ASAP.

JeffBezanson added a commit that referenced this pull request Aug 26, 2015
@JeffBezanson JeffBezanson merged commit aa8cd2e into master Aug 26, 2015
@vtjnash vtjnash deleted the jn/processpipe_cleanup branch August 26, 2015 02:42
@vtjnash
Copy link
Member Author

vtjnash commented Aug 26, 2015

That's great; then we can merge this ASAP.

yep, that was exactly the point. and as promised, the new PR is #12807

@JeffBezanson
Copy link
Member

Note: needs NEWS update for the rename of pipe, and to mention Pipe().

vtjnash added a commit that referenced this pull request Aug 26, 2015
Keno added a commit that referenced this pull request Aug 26, 2016
These probably should have been cleaned up along side that in #12739.
Certainly the documentation was out of date, since it referred to `Pipe`,
but meant what is now called `PipeEndpoint`. Clean all of this up, by
allowing an unitinalized `Pipe` to be passed to these functions, and
also by replacing the tuple of `PipeEndpoint`s, by `Pipe`, since the
purpose of `Pipe` is precisely to hold two endpoints.
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.

InexactError on failed spawn Add STDERR pipe to readandwrite use of open() results or filehandles
8 participants