[Python-Dev] PEP 554 v2 (new "interpreters" module)
Antoine Pitrou
solipsis at pitrou.net
Sat Sep 9 07:45:13 EDT 2017
More information about the Python-Dev mailing list
Sat Sep 9 07:45:13 EDT 2017
- Previous message (by thread): [Python-Dev] PEP 554 v2 (new "interpreters" module)
- Next message (by thread): [Python-Dev] PEP 554 v2 (new "interpreters" module)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, 9 Sep 2017 09:04:59 +0100 Paul Moore <p.f.moore at gmail.com> wrote: > On 9 September 2017 at 00:04, Eric Snow <ericsnowcurrently at gmail.com> wrote: > > add_recv_fifo(name=None): > > > > Create a new FIFO, associate the two ends with the involved > > interpreters, and return the side associated with the interpreter > > in which "add_recv_fifo()" was called. A FIFOReader gets tied to > > this interpreter. A FIFOWriter gets tied to the interpreter that > > called "add_recv_fifo()". > > > > The FIFO's name is set to the provided value. If no name is > > provided then a dynamically generated one is used. If a FIFO > > with the given name is already associated with this interpreter > > (or with the one in which "add_recv_fifo()" was called) then raise > > KeyError. > > > > add_send_fifo(name=None): > > > > Create a new FIFO, associate the two ends with the involved > > interpreters, and return the side associated with the interpreter > > in which "add_recv_fifo()" was called. A FIFOWriter gets tied to > > this interpreter. A FIFOReader gets tied to the interpreter that > > called "add_recv_fifo()". > > > > The FIFO's name is set to the provided value. If no name is > > provided then a dynamically generated one is used. If a FIFO > > with the given name is already associated with this interpreter > > (or with the one in which "add_send_fifo()" was called) then raise > > KeyError. > > Personally, I *always* read these names backwards - from the POV of > the caller. So when I see "add_send_fifo", I then expect to be able to > send stuff on the returned FIFO (i.e., I get a writer back). But > that's not how it works. Hmm, it's even worse for me, as it's not obvious by the quoted excerpt how those APIs are supposed to be used exactly. How does the other interpreter get the FIFO "tied" to it? Is it `get_current().get_fifo(name)`? Something else? How does it get to learn the *name*? Why are FIFOs unidirectional? Does it really make them significantly cheaper? With bidirectional pipes, the whole recv/send confusion would be avoided. As a point of comparison, for default for `multiprocessing.Pipe()` is to create a bidirectional pipe (*), yet I'm sure a multiprocessing Pipe has more overhead than an in-process FIFO. (*) https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Pipe Regards Antoine.
- Previous message (by thread): [Python-Dev] PEP 554 v2 (new "interpreters" module)
- Next message (by thread): [Python-Dev] PEP 554 v2 (new "interpreters" module)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Python-Dev mailing list