Matt Joiner <anacro...@gmail.com> added the comment: As I see it, here are the desirable features of CSP-style concurrency as it pertains to channels:
1) At least an unbuffered mode 2) Can be marked closed 3) Block on multiple send/receives until one can proceed Specifically features 1 and 2 could be bolted onto queue.Queue with excellent backward compatibility with existing usage of Queue. As mentioned on the mailing list, maxsize=None would mean infinite queue, and maxsize=0 would become the unbuffered mode Currently maxsize<=0 means infinite. Existing code that assumed one or the other and explicitly created Queues this way would have to change (I'd suspect almost no code would be affected). Feature 3 allows for all the awesomeness of CSP channels, but I think it requires a redesign under the covers of Queue to allow waiters to be woken from arbitrary Queues to which they are subscribed. The synchronization internals are quite complex. There appears to be several ways to proceed: 1) Add unbuffered mode, closing, and other syntactical sugar to queue.Queue. 2) Do (1) and additionally rework the internals to allow blocking on on several Queue actions at once. 3) Add an unbuffered-only, closable threading.Channel for use with higher level primitives (as Guido suggested). 4) Make no changes to queue, and create a brand-new module with full blown CSP channels. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14060> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
