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 paravoid
Recipients paravoid
Date 2020-05-03.15:33:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1588520007.12.0.424273214975.issue40485@roundup.psfhosted.org>
In-reply-to
Content
In certain codebases, it's useful to be able to wait for input from one or more file descriptors (e.g. a socket), while at the same time waiting for an event triggered by another thread, or perhaps multiprocessing process.

To wait for one or more file descriptors to get ready, the select module can be used. However, neither threading.Event() nor multiprocessing.Event() are select-able, i.e. they provide no fileno() method.

The standard way one can implement this on Unix is with os.pipe(), but it can be tricky (forgetting to use non-blocking I/O etc.). It is also limited to a pair of processes at a time. On Linux systems from the past decade, one can also implement this much more efficiently using the eventfd() system calls. I think similar functionality exists in other Unixes with kqueue etc.

It'd be great if stdlib provided an abstraction over this mechanism. In fact, multiprocessing.Event() itself could probably be a thin abstraction over eventfd() on Linux? Perhaps even multiprocessing.Semaphore with EFD_SEMAPHORE, although I admit I'm less familiar with how all that works.

(Select-able Queues would be even neater, but that's a story for a different issue :)
History
Date User Action Args
2020-05-03 15:33:27paravoidsetrecipients: + paravoid
2020-05-03 15:33:27paravoidsetmessageid: <1588520007.12.0.424273214975.issue40485@roundup.psfhosted.org>
2020-05-03 15:33:27paravoidlinkissue40485 messages
2020-05-03 15:33:26paravoidcreate