Understanding why getaddrinfo_a and __gai_enqueue_request use recursive locks

[Will Hawkins <whh8b at virginia dot edu>]

Hello!

Thank you all for your willingness to be part of the community of
glibc developers and for being so helpful when a novice like me has a
stupid question!

I was looking at the source code for getaddrinfo_a and noticed that it
calls __gai_enqueue_request. The former takes the __gai_requests_mutex
lock at the beginning of its work. The latter does the exact same
thing.

I understand that this will not deadlock because __gai_requests_mutex
is declared as a recursive lock, but I can't see the reason for
locking in both places.

I could imagine that it would be necessary if getaddrinfo_a or
__gai_enqueue_request called itself recursively or both the functions
were publicly accessible but neither of those seems to be the case. It
seems that getaddrinfo_a is the only function that calls
__gai_enqueue_request.

Is this somehow related to the "removal of internal function" change
that Mr. Weimer committed a few months ago (commit ca2085)? In other
words, is this meant to future proof the possibility that someone (a
non-internal user of glibc) calls __gai_enqueue_request directly?

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!

Thanks in advance!

Will