On Fri, Feb 8, 2013 at 1:06 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:

Le Thu, 7 Feb 2013 16:18:14 -0800, Nikolay Kim <fafhrd91@gmail.com> a écrit :

...

I think Tulip should have synchronization primitives by default. Here is my motivation:

1. it is more convenient to use locking primitive with existing semantics rather than tulip magic. crawl.py example could use semaphore instead of tasks.wait with timeout 0. 2. while it seems easy to implement semaphore with tulip, it still requires deep understanding of tulips control flow. i had 2 not very obvious bugs in my semaphore implementation:

a) release() could be called from different co-routines during same scheduling step. b) bug with acquire and release during same scheduling step. example: 1. task tries to acquire locked semaphore 2. other task releases semaphore

in result - semaphore gets acquired 2 times at the end of scheduling step, because actual semaphore acquisition happens in "call_soon" and at this stage release() call is already released semaphore but first waiter does not acquire it yet.

I think Twisted has DeferredSemaphore for the same reasons.

So, is anyone against adding Nikolay's locks implementation to PEP 3156? It's a pretty simple API, and looks similar to the locks in threading.py except for a sprinkling of "yield from". It does not depend on Tulip internals. -- --Guido van Rossum (python.org/~guido)

On Fri, Feb 8, 2013 at 1:06 AM, Antoine Pitrou <solipsis@pitrou.net> wrote:

Le Thu, 7 Feb 2013 16:18:14 -0800, Nikolay Kim <fafhrd91@gmail.com> a écrit :

...

I think Tulip should have synchronization primitives by default. Here is my motivation:

1. it is more convenient to use locking primitive with existing semantics rather than tulip magic. crawl.py example could use semaphore instead of tasks.wait with timeout 0. 2. while it seems easy to implement semaphore with tulip, it still requires deep understanding of tulips control flow. i had 2 not very obvious bugs in my semaphore implementation:

a) release() could be called from different co-routines during same scheduling step. b) bug with acquire and release during same scheduling step. example: 1. task tries to acquire locked semaphore 2. other task releases semaphore

in result - semaphore gets acquired 2 times at the end of scheduling step, because actual semaphore acquisition happens in "call_soon" and at this stage release() call is already released semaphore but first waiter does not acquire it yet.

I think Twisted has DeferredSemaphore for the same reasons.

So, is anyone against adding Nikolay's locks implementation to PEP 3156? It's a pretty simple API, and looks similar to the locks in threading.py except for a sprinkling of "yield from". It does not depend on Tulip internals. -- --Guido van Rossum (python.org/~guido)