-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
process and pipe cleanup #12739
Conversation
iswritable(::DevNullStream) = true | ||
isopen(::DevNullStream) = true | ||
read{T<:DevNullStream}(::T, args...) = throw(EOFErorr()) | ||
write{T<:DevNullStream}(::T, args...) = 0 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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"
There was a problem hiding this comment.
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.
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? |
fixed. i have no idea how that got into my paste buffer
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.
I'm not sure, so the deprecation should happen in a separate PR. |
Looks like a small memory leak can only happen if |
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) |
8d17387
to
7825dc4
Compare
Merge the Pipe() and Pipe(C_NULL) constructors having the former just call the latter and delaying initialization to the place where it is actually needed. Now passing an empty Pipe to spawn will once again initialize it with the appropriate pipe end.
…. also rename Pipe to PipeEndpoint
… appropriate stdin/stdout stream
…e a hidden argument rather than an awkward first argument
7825dc4
to
2f24987
Compare
PipeEndpoint has behavioral flaws when used on its own since it is incapable of tracking the full pipe and the behavior of both ends
overdue so long
…2):typemax(UInt32) that may be returned by spawn on windows (fixes #12176)
2f24987
to
c565cd0
Compare
Thank you for including #12050. |
https://github.com/search?l=julia&q=jl_alloca&type=Code&utf8=%E2%9C%93 Looks like no, except for various forks of Julia |
Is this good to merge now? Looks like the last major thing in the way for 0.4 RCs. |
yes. however, since this is breaking for the definition of |
That is literally the worst reason to delay merging something I've ever heard. |
+1 |
That's my deadline for hitting the merge button. I won't hinder anyone else from merging it sooner. |
Please merge. We are pretty close to the branch point. |
@JeffBezanson, please merge if you're happy with this. |
My main concern is that the change to |
agreed, i've taken out the change to |
for separation into a independent merge commit
3c295ed
to
8ffdfc2
Compare
That's great; then we can merge this ASAP. |
yep, that was exactly the point. and as promised, the new PR is #12807 |
Note: needs |
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.
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:
cat
#11919 (which also fixes Add STDERR pipe toreadandwrite
#11824)fixes use of open() results or filehandles #9659 by changing[this item is moving to a new PR]open(Cmd)
to only return a Process, defining IO operations on Process, and definingclose(Process)
to meanclose(Process.in) && close(Process.out)
. this is a breaking change, since i know of no way to sanely provide a deprecation for this (I would prefer not to define iteration over a Process object as returning the old tuple of(io, process)
)Intrinsics.Box(Ptr{Void},Intrinsics.jl_alloca(size))
from Base (preferring the possibility of a small memory leak in exceptional cases instead of segfaults), in preparation for deprecating this intrinsic functionPipe