Understanding why getaddrinfo_a and __gai_enqueue_request use recursive locks

[Will Hawkins]

On Sat, Sep 23, 2017 at 9:04 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 09/23/2017 01:08 AM, Will Hawkins wrote:
>> I am sure that there is a very subtle explanation for what is going on
>> here, but my mind is too simple to get it. I know that the code works,
>> but I am curious about why.
>>
>> If you can shed any light on the situation, I'd really appreciate it!
>
> It is a design principle. Acquire the lock if you inspect data that could
> be concurrently modified.

Thank you! This makes perfect sense, of course. Obviously with an
asynchronous function that is implemented with concurrent access to
shared data structures in a multithreaded world, mutexes are our
friends. :-)

>
> You are correct that it looks like the list lock acquisition could be
> removed from __gai_enqueue_request. That would be an optimization.
> The comments even say so themselves.

This is what confused me -- thank you for the confirmation that I was
not going crazy! After an hour of trying to figure out how the code
did not deadlock every time, I finally looked at the
initialization/definition of the mutex and saw that it was recursive.

>
> Patches welcome! :-)
>

This will be awesome! I'd love to contribute. I am in/out for the next
several days but I will submit it asap!

> Please don't be too scared about the contribution checklist, we can
> help with any step along the way:
>
> https://sourceware.org/glibc/wiki/Contribution%20checklist
>

Thank you so much for taking the time to reply and encouraging my
participation. Talk to you soon!

Will

> --
> Cheers,
> Carlos.