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 andresfreund
Recipients TarkaSteve, andresfreund, jnoller, roudkerk
Date 2010-06-09.06:34:05
SpamBayes Score 0.058409892
Marked as misclassified No
Message-id <1276065248.55.0.942732814245.issue3831@psf.upfronthosting.co.za>
In-reply-to
Content
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 have a hard time seing that as a problem as that should be both rare and only last a short time.

My personal use-case is being able to efficiently wait for evens from different queues - using the standard api one currently can only do that by busy looping...

The biggest thing I see where you have to be careful here is some stomping herd phenomenon you will get into if you have multiple readers doing a poll().
Namely *all* off those processes will awake and run into .get() which isnt exactly nice, but thats hardly solvable on python level.
History
Date User Action Args
2010-06-09 06:34:08andresfreundsetrecipients: + andresfreund, roudkerk, jnoller, TarkaSteve
2010-06-09 06:34:08andresfreundsetmessageid: <1276065248.55.0.942732814245.issue3831@psf.upfronthosting.co.za>
2010-06-09 06:34:06andresfreundlinkissue3831 messages
2010-06-09 06:34:05andresfreundcreate