On Tue, Jun 27, 2017 at 3:48 PM, Nathaniel Smith wrote:
> On Tue, Jun 27, 2017 at 4:15 AM, Chris Jerdonek
>> Thinking through the requirements I want for my RW synchronization use
>> case in more detail, I think I want the completion of any "write" to
>> be followed by exhausting all "reads." I'm
On Tue, Jun 27, 2017 at 4:15 AM, Chris Jerdonek
wrote:
> On Tue, Jun 27, 2017 at 3:29 AM, Nathaniel Smith wrote:
>> In fact asyncio.Lock's implementation is careful to maintain strict
>> FIFO fairness, i.e. whoever calls acquire() first is guaranteed to get
>> the lock first. Whether this is some
On Tue, Jun 27, 2017 at 3:29 AM, Nathaniel Smith wrote:
> In fact asyncio.Lock's implementation is careful to maintain strict
> FIFO fairness, i.e. whoever calls acquire() first is guaranteed to get
> the lock first. Whether this is something you feel you can depend on
> I'll leave to your conscie
On Tue, Jun 27, 2017 at 12:29 AM, Chris Jerdonek
wrote:
> I have a couple questions about asyncio's synchronization primitives.
>
> Say a coroutine acquires an asyncio Condition's underlying lock, calls
> notify() (or notify_all()), and then releases the lock. In terms of
> which coroutines will a
AFAIK No any guarantee
On Tue, Jun 27, 2017 at 10:29 AM Chris Jerdonek
wrote:
> I have a couple questions about asyncio's synchronization primitives.
>
> Say a coroutine acquires an asyncio Condition's underlying lock, calls
> notify() (or notify_all()), and then releases the lock. In terms of
>
I have a couple questions about asyncio's synchronization primitives.
Say a coroutine acquires an asyncio Condition's underlying lock, calls
notify() (or notify_all()), and then releases the lock. In terms of
which coroutines will acquire the lock next, is any preference given
between (1) coroutin
