Re: [PATCH v2 3/4] Move libio lock single-thread optimization to generic libc-lock (BZ #27842)

[Florian Weimer <fweimer@redhat.com>]

* Wilco Dijkstra:

> Hi Adhemerval,
>
>> The main problem is _IO_enable_locks is a clunky interface because it requires
>> flockfile to set _flags2 outside a lock region leading a possible racy issue 
>> (BZ #27842).  Moving to lock itself it will pretty much:
>
> It should be fine if we use a boolean instead of a flag. IIRC the IO
> structure was externally exposed in Emacs, but if that is no longer
> the case then we could change the structure safely.

gnulib has code that directly _flags (not _flags2).  gnulib is
statically linked, which makes for a long transition time.

>> I think ideally we would like to model all internal locks to a futex-like
>> so we can use the congestion optimization as described by Jens Gustedt
>> paper [1] which would allows us to move the counter and the lock to
>> same word.  I don't think we can improve recursive locks without a 64-bit
>> futex operation. 
>
> How much lock recursion exists in GLIBC? An 8-bit counter is likely
> sufficient...

One of the loader logs is recursive, and dlopen calls can be nested
basically arbitrarily deeply in ELF constructors.

Thanks,
Florian