[Python-ideas] PEP 3156 / Tulip: Synchronization primitives

[Guido van Rossum]

On Fri, Feb 8, 2013 at 1:06 AM, Antoine Pitrou <solipsis at pitrou.net> wrote:
> Le Thu, 7 Feb 2013 16:18:14 -0800,
> Nikolay Kim <fafhrd91 at 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)