
On 26 September 2017 at 17:04, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Mon, 25 Sep 2017 17:42:02 -0700 Nathaniel Smith <njs@pobox.com> wrote:
Unbounded queues also introduce unbounded latency and memory usage in realistic situations.
This doesn't seem to pose much a problem in common use cases, though. How many Python programs have you seen switch from an unbounded to a bounded Queue to solve this problem?
Conversely, choosing a buffer size is tricky. How do you know up front which amount you need? Is a fixed buffer size even ok or do you want it to fluctuate based on the current conditions?
And regardless, my point was that a buffer is desirable. That send() may block when the buffer is full doesn't change that it won't block in the common case.
It's also the case that unlike Go channels, which were designed from scratch on the basis of implementing pure CSP, Python has an established behavioural precedent in the APIs of queue.Queue and collections.deque: they're unbounded by default, and you have to opt in to making them bounded.
There's a reason why sockets always have bounded buffers -- it's sometimes painful, but the pain is intrinsic to building distributed systems, and unbounded buffers just paper over it.
Papering over a problem is sometimes the right answer actually :-) For example, most Python programs assume memory is unbounded...
If I'm using a queue or channel to push events to a logging system, should I really block at every send() call? Most probably I'd rather run ahead instead.
While the article title is clickbaity, http://www.jtolds.com/writing/2016/03/go-channels-are-bad-and-you-should-fee... actually has a good discussion of this point. Search for "compose" to find the relevant section ("Channels don’t compose well with other concurrency primitives"). The specific problem cited is that only offering unbuffered or bounded-buffer channels means that every send call becomes a potential deadlock scenario, as all that needs to happen is for you to be holding a different synchronisation primitive when the send call blocks.
Also, suddenly an interpreter's ability to exploit CPU time is dependent on another interpreter's ability to consume data in a timely manner (what if the other interpreter is e.g. stuck on some disk I/O?). IMHO it would be better not to have such coupling.
A small buffer probably is useful in some cases, yeah -- basically enough to smooth out scheduler jitter.
That's not about scheduler jitter, but catering for activities which occur at inherently different speed or rhythms. Requiring things run in lockstep removes a lot of flexibility and makes it harder to exploit CPU resources fully.
The fact that the proposal now allows for M:N sender:receiver relationships (just as queue.Queue does with threads) makes that problem worse, since you may now have variability not only on the message consumption side, but also on the message production side. Consider this example where you have an event processing thread pool that we're attempting to isolate from blocking IO by using channels rather than coroutines. Desired flow: 1. Listener thread receives external message from socket 2. Listener thread files message for processing on receive channel 3. Listener thread returns to blocking on the receive socket 4. Processing thread picks up message from receive channel 5. Processing thread processes message 6. Processing thread puts reply on the send channel 7. Sending thread picks up message from send channel 8. Sending thread makes a blocking network send call to transmit the message 9. Sending thread returns to blocking on the send channel When queue.Queue is used to pass the messages between threads, such an arrangement will be effectively non-blocking as long as the send rate is greater than or equal to the receive rate. However, the GIL means it won't exploit all available cores, even if we create multiple processing threads: you have to switch to multiprocessing for that, with all the extra overhead that entails. So I see the essential premise of PEP 554 as being to ask the question "If each of these threads was running its own *interpreter*, could we use Sans IO style protocols with interpreter channels to separate internally "synchronous" processing threads from separate IO threads operating at system boundaries, without having to make the entire application pervasively asynchronous?" If channels are an unbuffered blocking primitive, then we don't get that benefit: even when there are additional receive messages to be processed, the processing thread will block until the previous send has completed. Switching the listener and sender threads over to asynchronous IO would help with that, but they'd also end up having to implement their own message buffering to manage the lack of buffering in the core channel primitive. By contrast, if the core channels are designed to offer an unbounded buffer by default, then you can get close-to-CSP semantics just by setting the buffer size to 1 (it's still not exactly CSP, since that has a buffer size of 0, but you at least get the semantics of having to alternate sending and receiving of messages).
I expect more often than expected, in complex systems :-) For example, you could have a recv() loop that also from time to time send()s some data on another queue, depending on what is received. But if that send()'s recipient also has the same structure (a recv() loop which send()s from time to time), then it's easy to imagine to two getting in a deadlock.
You kind of want to be able to create deadlocks, since the alternative is processes that can't coordinate and end up stuck in livelocks or with unbounded memory use etc.
I am not advocating we make it *impossible* to create deadlocks; just saying we should not make them more *likely* than they need to.
Right, and I think the queue.Queue and collections.deque model works well for that, since you can start introducing queue bounds to propagate backpressure through a system if you're seeing undesirable memory growth.
It's fairly reasonable to implement a mutex using a CSP-style unbuffered channel (send = acquire, receive = release). And the same trick turns a channel with a fixed-size buffer into a bounded semaphore. It won't be as efficient as a modern specialized mutex implementation, of course, but it's workable.
We are drifting away from the point I was trying to make here. I was pointing out that the claim that nothing can be shared is a lie. If it's possible to share a small datum (a synchronized counter aka semaphore) between processes, certainly there's no technical reason that should prevent it between interpreters.
By the way, I do think efficiency is a concern here. Otherwise subinterpreters don't even have a point (just use multiprocessing).
Agreed, and I think the interaction between the threading module and the interpreters module is one we're going to have to explicitly call out as being covered by the provisional status of the interpreters module, as I think it could be incredibly valuable to be able to send at least some threading objects through channels, and have them be an interpreter-specific reference to a common underlying sync primitive.
Unfortunately while technically you can construct a buffered channel out of an unbuffered channel, the construction's pretty unreasonable (it needs two dedicated threads per channel).
And the reverse is quite cumbersome as well. So we should favour the construct that's more convenient for users, or provide both.
As noted above, I think consistency with design intuitions formed through the use of queue.Queue is also an important consideration. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia