After having looked it over, I'm leaning toward supporting buffering,
as well as not blocking by default. Neither adds much complexity to
the implementation.
On Sat, Sep 23, 2017 at 5:45 AM, Antoine Pitrou <solip...@pitrou.net> wrote:
> On Fri, 22 Sep 2017 19:09:01 -0600
> Eric Snow <ericsnowcurren...@gmail.com> wrote:
>> > send() blocking until someone else calls recv() is not only bad for
>> > performance,
>>
>> What is the performance problem?
>
> Intuitively, there must be some kind of context switch (interpreter
> switch?) at each send() call to let the other end receive the data,
> since you don't have any internal buffering.
There would be an internal size-1 buffer.
>> (FWIW, CSP
>> provides rigorous guarantees about deadlock detection (which Go
>> leverages), though I'm not sure how much benefit that can offer such a
>> dynamic language as Python.)
>
> Hmm... deadlock detection is one thing, but when detected you must still
> solve those deadlock issues, right?
Yeah, I haven't given much thought into how we could leverage that
capability but my
gut feeling is that we won't have much opportunity to do so. :)
>> I'm not sure I understand your concern here. Perhaps I used the word
>> "sharing" too ambiguously? By "sharing" I mean that the two actors
>> have read access to something that at least one of them can modify.
>> If they both only have read-only access then it's effectively the same
>> as if they are not sharing.
>
> Right. What I mean is that you *can* share very simple "data" under
> the form of synchronization primitives. You may want to synchronize
> your interpreters even they don't share user-visible memory areas. The
> point of synchronization is not only to avoid memory corruption but
> also to regulate and orchestrate processing amongst multiple workers
> (for example processes or interpreters). For example, a semaphore is
> an easy way to implement "I want no more than N workers to do this
> thing at the same time" ("this thing" can be something such as disk
> I/O).
I'm still not convinced that sharing synchronization primitives is
important enough to be worth including it in the PEP. It can be added
later, or via an extension module in the meantime. To that end, I'll
add a mechanism to the PEP for third-party types to indicate that they
can be passed through channels. Something like
"obj.__channel_support__ = True".
-eric
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
