I don't see the relevance of recursiveness, a non-block lock can be
recursive. What "other threads" do you mean? Are the blocking locks
rare enough that we could implement them with brief usleep() and a
retry?
On Wed, Nov 28, 2018 at 2:13 PM Alan Carroll <solidwallofc...@oath.com> wrote:
>
> Because having the locks be recursive is a critical feature due to the tail
> recursion used in event handling. And there are places (in other threads)
> where blocking locks on Continuations are used.
>
> On Wed, Nov 28, 2018 at 12:20 PM Walt Karas <wka...@oath.com.invalid> wrote:
>>
>> Why can't the mutexes for continuations simply use test-and-set. We
>> only ever try to lock them (and requeue the continuation if lock is
>> not available), correct? Since it's hard to be sure in TS when a
>> continuation does or does not need a lock, it would be nice if one
>> could be used defensively with less overhead.
>
>
>
> --
> Beware the fisherman who's casting out his line in to a dried up riverbed.
> Oh don't try to tell him 'cause he won't believe. Throw some bread to the
> ducks instead.
> It's easier that way. - Genesis : Duke : VI 25-28
