Discussion:
getprotobyname -- thread local or _r?
(too old to reply)
Jay K
2018-08-18 23:16:18 UTC
Permalink
Hi. This is probably an ancient topic and I didn't search the archives yet.

A quick survey of operating system man pages says that in the vast majority of cases, either getprotobyname etc. returns data in a thread local, or getprotobyname_r, etc. are provided.

getprotobyname uses thread local: OpenBSD, FreeBSD, NT, MacOSX.
getprotobyname_r is provided: Linux, HP-UX, AIX, Solaris.
Sometimes both: Tru64 (_r for compat, thread local for "real").
No-op: Android?

NetBSD seems to be the outlier here.

Some people suggest to wrap one's own users in a lock, but this does not suffice. Everyone's uses within a process must be wrapped with the same lock. And not everyone can be coordinated to do so.

Can this please be "fixed"?

Thank you,
 - Jay




--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Jonathan A. Kollasch
2018-08-19 15:17:35 UTC
Permalink
Post by Jay K
Hi. This is probably an ancient topic and I didn't search the archives yet.
A quick survey of operating system man pages says that in the vast majority of cases, either getprotobyname etc. returns data in a thread local, or getprotobyname_r, etc. are provided.
getprotobyname uses thread local: OpenBSD, FreeBSD, NT, MacOSX.
getprotobyname_r is provided: Linux, HP-UX, AIX, Solaris.
Sometimes both: Tru64 (_r for compat, thread local for "real").
No-op: Android?
NetBSD seems to be the outlier here.
Some people suggest to wrap one's own users in a lock, but this does not suffice. Everyone's uses within a process must be wrapped with the same lock. And not everyone can be coordinated to do so.
Can this please be "fixed"?
POSIX doesn't require this function to be thread safe. So you can't
ever assume it will be. That said, it probably should be made thread-safe
in NetBSD. Could you just use getaddrinfo instead?

Jonathan Kollasch

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de
Loading...