getaddrinfo_a

[Marcin 'Qrczak' Kowalczyk <qrczak at knm dot org dot pl>]

http://people.redhat.com/drepper/asynchnl.pdf says that gai_suspend
returns EAI_INTR when a signal interrupted it.

The glibc implementation uses pthread_cond_wait. It's unspecified
whether handling a signal causes a spurious wakeup or whether
pthread_cond_wait continues to wait; it never returns EINTR.
On Linux with NPTL it seems to continue to wait.

But gai_suspend returns EAI_INTR when pthread_cond_wait returned
EINTR, which is impossible. In addition it's not protected against
spurious wakeups: it will just return 0, even though name lookup has
not finished.

Should I file a bug report?

* * *

The paper hints that gai_cancel can be implemented by canceling
a thread. But glibc does not try that - judging from the code it
only removes it from a queue if the worker thread has not started
processing it. While it's theoretically correct, it would be a bit
better if a request could be canceled more often.

Well, since I can't rely on the ability to cancel anyway, I must be
prepared to keep the struct gaicb in memory until the request finishes,
even if I'm no longer interested in its result. It's a pity that it
can't be always canceled.

* * *

Given that there is no asynchronous variant of getnameinfo, I think I
will not use getaddrinfo_a at all, but use pthreads with getaddrinfo /
getnameinfo. I will synchronize threads with a pipe in order for
waiting to be interruptible by a singal. Or is there a better way?
I would not use pthreads otherwise.

Is it safe to call pthread_cancel on a thread which uses getaddrinfo /
getnameinfo, or it may leak memory?

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/