Le Thu, 7 Feb 2013 16:18:14 -0800, Nikolay Kim firstname.lastname@example.org a écrit :
I think Tulip should have synchronization primitives by default. Here is my motivation:
- 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.