[Python-Dev] PEP 3145 (With Contents)

[anatoly techtonik]

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
http://docs.python.org/2/library/select ?
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...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20121220/1ddd4387/attachment.html>