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
Multiprocessing: Expose underlying pipe in queues #48081
Comments
Both Connection and Pipe objects expose their underlying file |
Steve, I'm a little nervous about exposing the underlying Queue pipes in Do you have an example use-case/code? This will not be making it into |
Hi Jesse, The use-case I had is mind is enabling asyncronous (i.e. select() style) http://haltcondition.net/?p=2319 I understand wanting to keep the API simple, however the underlying Would it help if I attached a patch showing the proposed change to the |
Can you please provide an example w.r.t to how you would handle the case |
As soon as some bytes are signalled as being available one can simply do a normal get(). I don't really see the problem here? My personal use-case is being able to efficiently wait for evens from different queues - using the standard api one currently can only do that by busy looping... The biggest thing I see where you have to be careful here is some stomping herd phenomenon you will get into if you have multiple readers doing a poll(). |
I look forward to this, or something similar. Inspiration can be taken from Golangs's select behaviour on channels. select { default: |
This would be useful much as commented in code using the style of go of waiting for multiple channels. Maybe exposing the reader is too much but either adding a |
The same would also be true for the rest of the synchronisation primitives in the multiprocessing library. Right now the only way to do this seems to be to resort to having threads waiting for each non-selectable primitive that can then either set a central Event or post to a Pipe/Connection that can be selected on. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: