Understanding why getaddrinfo_a and __gai_enqueue_request use recursive locks
Will Hawkins
whh8b@virginia.edu
Sat Sep 23 07:08:00 GMT 2017
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
More information about the Libc-help
mailing list