This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author sbt
Recipients Erez.Sh, William.Edwards, asksol, danken, dmalcolm, giampaolo.rodola, jnoller, pitrou, sbt, synapse, vstinner
Date 2012-10-22.18:47:42
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1350931662.34.0.698750620407.issue10527@psf.upfronthosting.co.za>
In-reply-to
Content
> Using poll() by default is controversial for 2 reasons, I think:
>
> #1 - a certain slowdown is likely to be introduced (I'll measure it)

With a single fd poll is a bit faster than select:

$ python -m timeit -s 'from select import select' 'select([0],[],[],0)'
100000 loops, best of 3: 2.99 usec per loop

$ python -m timeit -s 'from select import poll, POLLIN' 'p=poll();p.register(0,POLLIN);p.poll(0)'
100000 loops, best of 3: 2.8 usec per loop

The single fd case is the most important one -- see below.

> #2 - current wait() implementation allows to specify a list of file
> descriptors and/or Connections objects. 
> select() can deal with both while poll() does not (it will return a 
> list of integers rather than a list of Connection instances).
>
> I'm not sure how "public" multiprocessing.connection.wait() is 
> considered and how much backward compatibility should matter in this > case.

It was introduced in Python 3.3 and is only really there to allow cross platform Windows/Unix multiplexing.  It is (now) also used internally by Connection.poll() and Queue.get() with a single fd.

In retrospect it would probably have been better to have implemented poll style multiplexing on Windows.
History
Date User Action Args
2012-10-22 18:47:42sbtsetrecipients: + sbt, pitrou, vstinner, giampaolo.rodola, jnoller, synapse, asksol, dmalcolm, danken, Erez.Sh, William.Edwards
2012-10-22 18:47:42sbtsetmessageid: <1350931662.34.0.698750620407.issue10527@psf.upfronthosting.co.za>
2012-10-22 18:47:42sbtlinkissue10527 messages
2012-10-22 18:47:42sbtcreate