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 William.Edwards, giampaolo.rodola, sbt
Date 2012-10-17.23:37:59
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1350517079.34.0.849920138537.issue16269@psf.upfronthosting.co.za>
In-reply-to
Content
> select() other than being supported on all platforms has the advantage of 
> being simple and quick to use (you just call it once by passing a set of fds 
> and then you're done).

Do you mean at the C level?  Wouldn't you just do

  struct pollfd pfd = {fd, POLLIN, 0};
  if (poll(&pfd, 1, timeout) < 0) {...}
  ready = pfd.revents != 0;

That does not look any less simple and quick.

> on the other hand you introduce a considerable slowdown given the amount 
> of operations involved and described above.

poll(), unlike select(), does not have to scan an fd_set (of 1024 bits?) so I would have expected it to be faster if anything.

At the python level creating a new poll object each time might indeed be slower, but one could always cache it on the queue object.

BTW, are there any non-Windows platforms which support multiprocessing but don't have poll()?  (On Windows WaitForSingleObject() is used instead.)
History
Date User Action Args
2012-10-17 23:37:59sbtsetrecipients: + sbt, giampaolo.rodola, William.Edwards
2012-10-17 23:37:59sbtsetmessageid: <1350517079.34.0.849920138537.issue16269@psf.upfronthosting.co.za>
2012-10-17 23:37:59sbtlinkissue16269 messages
2012-10-17 23:37:59sbtcreate