views:

72

answers:

2

Is inet_aton Thread-Safe? I know according to UNP that POSIX doesn't require a lot of the Sockets API to be thread safe, and so I have to assume they're not, but in general how do I know if something is thread safe in Perl? To what extent do I need to lock library function that I call? And how do I lock them? When I try something like lock(&inet_aton) it gives me an error: Can't modify non-lvalue subroutine call in lock.

And yes, I've read: Thread-Safety of System Libraries

+2  A: 

If you read the inet_aton manpage carefully you will see that this call does not use any shared state (contrary to the inet_ntoa function described in the same manpage), and thus should be thread safe.

That the function writes its result into a caller-provided structure also supports this.

Perl uses a thin wrapper on top of those functions and thus doesn't change the thread safety of the underlying library.

David Schmitt
So in general, how do I evaluate thread safety in relation to library calls? I read this about reentrancy in POSIX: http://www.unix.org/whitepapers/reentrant.html It seems to indicate static data / state as the main thing to look for. I guess I just need to check on a func by func basis. So if I needed for instance to call `inet_ntoa` how could I lock it?
Robert S. Barnes
+2  A: 

The function inet_aton doesn't have any state it keeps between function calls, so I don't see any reason why it wouldn't be thread safe (provided the arguments you pass it aren't shared between threads).

Leon Timmermans
Usage of global static variables or global external state (e.g. hardware clock), even without statefulness, I believe is a potential issue.
mctylr