[Python-ideas] channel (synchronous queue)

[Cameron Simpson]

On 18Feb2012 20:01, Antoine Pitrou <solipsis at pitrou.net> wrote:
| On Sat, 18 Feb 2012 23:38:06 +0800
| Matt Joiner <anacrolix at gmail.com> wrote:
| > Recently (for some) the CSP style of channel has become quite popular
| > in concurrency implementations. This kind of channel allows sends that
| > do not complete until a receiver has actually taken the item. The
| > existing  queue.Queue would act like this if it didn't treat a queue
| > size of 0 as infinite capacity.
| > 
| > In particular, I find channels to have value when sending data between
| > threads, where it doesn't make sense to proceed until some current
| > item has been accepted. This is useful when items are not purely CPU
| > bound, and so generators are not appropriate.
| 
| What is the point to process the data in another thread, if you are
| going to block on the result anyway?

Synchronisation. Shrug. I use synchronous channels myself; they are a
fine basic facility. The problem with Queues et al is that they are
inherently _asynchronous_ and you have to work hard to wrap locking
around it when you want interlocking cogs.

Also, it is perfectly reasonable in many circumstances to use a thread
for algorithmic clarity, just like you might use a generator or a
coroutine in suitable circumstances. Here one does it not so that some
work may process in parallel but to cleanly write two algorithms that
pass information between each other but are otherwise as separate as an
aother pair of functions might be. The alternative may be a complicated
interwoven event loop.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

C makes it easy for you to shoot yourself in the foot.  C++ makes that
harder, but when you do, it blows away your whole leg.
- Bjarne Stroustrup