[Python-Dev] PEP 3145 (With Contents)
techtonik at gmail.com
Wed Dec 19 23:14:47 CET 2012
On Sun, Dec 9, 2012 at 7:14 AM, Glyph <glyph at twistedmatrix.com> wrote:
> On Dec 7, 2012, at 5:10 PM, anatoly techtonik <techtonik at gmail.com> wrote:
> What about reading from other file descriptors? subprocess.Popen allows
>> arbitrary file descriptors to be used. Is there any provision here for
>> reading and writing non-blocking from or to those?
> On Windows it is WriteFile/ReadFile and PeekNamedPipe. On Linux it is
> select. Of course a test is needed, but why it should not just work?
> This is exactly why the provision needs to be made explicitly.
> On Windows it is WriteFile and ReadFile and PeekNamedPipe - unless the
> handle is a socket in which case it needs to be WSARecv. Or maybe it's
> some other weird thing - like, maybe a mailslot - and you need to call a
> different API.
IIRC on Windows there is no socket descriptor that can be used as a file
descriptor. Seems reasonable to limit the implementation to standard file
descriptors in this platform.
On *nix it really shouldn't be select. select cannot wait upon a file
> descriptor whose *value* is greater than FD_SETSIZE, which means it sets
> a hard (and small) limit on the number of things that a process which wants
> to use this facility can be doing.
I didn't know that. Should a note be added to
I also thought that poll acts like, well, a polling function - eating 100%
CPU while looping over inputs over and over checking if there is something
to react to.
> On the other hand, if you hard-code another arbitrary limit like this into
> the stdlib subprocess module, it will just be another great reason why
> Twisted's spawnProcess is the best and everyone should use it instead, so
> be my guest ;-).
spawnProcess requires a reactor. This PEP is an alternative for the
proponents of green energy. =)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev