[Python-Dev] PEP 554 v2 (new "interpreters" module)

[Eric Snow]

On Sat, Sep 9, 2017 at 4:45 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> How does the other interpreter get the FIFO "tied" to it?
> Is it `get_current().get_fifo(name)`?  Something else?

Yep, that's it.  I've added some examples to the PEP to illustrate.
That said, I'm re-working the method names since they confuse me too.
:)

>  How does it get to learn the *name*?

The main way is that the programmer hard-codes it.  I'd expect close
proximity between the code that adds the FIFO and the code that get's
run in the subinterpreter.

>
> 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.

The choice wasn't about cost or performance.  In part it's a result of
my experience with Go's channels.  Bidirectional channels are
problematic in certain situations, including when it relates to which
goroutine is responsible for managing the channel's lifetime.  Also,
bidirectional channels require both the reader and the writer (of the
code) to keep track of the two roles that the channel plays.  It's
easy to forget about one or the other, and accidentally do the wrong
thing.  Unidirectional channels resolve all those problems.  Granted,
the FIFOs from the PEP aren't the same as Go's channels.  They are
more rudimentary and they lack the support provided by a static
compiler (e.g. deadlock detection), but my intention is that they
provide all the functionality we need as a building block.

-eric