[issue3831] Multiprocessing: Expose underlying pipe in queues

Changes by Julian Mehnle : -- nosy: +jmehnle ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue3831] Multiprocessing: Expose underlying pipe in queues

Changes by B. Clausius : -- nosy: +barcc ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/

[issue3831] Multiprocessing: Expose underlying pipe in queues

Matt Joiner added the comment: I look forward to this, or something similar. Inspiration can be taken from Golangs's select behaviour on channels. select { case i1 = <-c1: print("received ", i1, " from c1\n") case c2 <- i2: print("sent ", i2, " to c2\n") default: print

[issue3831] Multiprocessing: Expose underlying pipe in queues

Changes by Matt Joiner : -- nosy: +anacrolix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue3831] Multiprocessing: Expose underlying pipe in queues

Changes by Forest Wilkinson : -- nosy: +forest ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue3831] Multiprocessing: Expose underlying pipe in queues

Changes by Ask Solem : -- nosy: +asksol ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/m

[issue3831] Multiprocessing: Expose underlying pipe in queues

Changes by Terry J. Reedy : -- versions: +Python 3.2 -Python 2.7, Python 3.1 ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue3831] Multiprocessing: Expose underlying pipe in queues

Andres Freund added the comment: 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? Sure, the get() might not be completely non-blocking (especially if the transferred event is more than the size of a pipe-buffer) but I

[issue3831] Multiprocessing: Expose underlying pipe in queues

Jesse Noller added the comment: Can you please provide an example w.r.t to how you would handle the case where poll()/recv returns partial bytes of the object instead of a full object? -- ___ Python tracker _

[issue3831] Multiprocessing: Expose underlying pipe in queues

Changes by Jesse Noller : -- priority: -> low ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue3831] Multiprocessing: Expose underlying pipe in queues

Steve Smith <[EMAIL PROTECTED]> added the comment: Hi Jesse, The use-case I had is mind is enabling asyncronous (i.e. select() style) notification of data being available on the queue, which is more elegant (and efficient) than polling with get(). Example code showing how this works with GTK is

[issue3831] Multiprocessing: Expose underlying pipe in queues

Jesse Noller <[EMAIL PROTECTED]> added the comment: Steve, I'm a little nervous about exposing the underlying Queue pipes in an official API simply due to the fact that it is an advanced use case, and we do want to keep the API simple, and relatively close to the core Queue implementation. Do

[issue3831] Multiprocessing: Expose underlying pipe in queues

Changes by Benjamin Peterson <[EMAIL PROTECTED]>: -- assignee: -> jnoller nosy: +jnoller ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3831] Multiprocessing: Expose underlying pipe in queues

New submission from Steve Smith <[EMAIL PROTECTED]>: Both Connection and Pipe objects expose their underlying file descriptors, which is useful for accessing them in an event-driven manner. However the higher-level Queue does not make the underlying pipe available; to get at them you must access