Front page | perl.perl5.porters |
Postings from January 2001
On Fri, Jan 26, 2001 at 12:43:28PM -0500, Dan Sugalski wrote: > At 04:58 PM 1/26/2001 +0000, Nicholas Clark wrote: > >And another. We're using gethostbyname. To quote an online Sun manpage: > > > >The functions gethostbyname() , gethostbyaddr() , and gethostent() use > >static storage that is reused in each call, making these functions unsafe > >for use in multi-threaded applications. > > > >The functions gethostbyname_r() , gethostbyaddr_r() , and gethostent_r() > >provide reentrant interfaces for these operations. > > > >[however, I don't know whether that many platforms provide the latter's > >functionality, and if so if they even use the same names] > > It depends on your platform--some have threadsafe gethost* calls and don't > need the _r version, and some don't. (And some aren't threadsafe but don't > have _r versions...) > > It's pretty much a crapshoot, unfortunately. Hmm. Maybe I'm missing something here. (I don't know much about threads) perl rapidly copies the data returned by gethostbyname into SVs If threaded perl had a gethostbyname mutex so that only one thread at a time could get into the area referencing the call to gethostbyname() and the returned (possibly static) structure, would this solve the problem (at least within perl, provided extensions don't call gethostbyname) What happens if a thread is killed while holding the mutex? [is this mutex the least of our worries in this case] > Don't even ask that question--I'd bet we don't really want the answer... :) integer overflow is undefined behaviour, so I've just added a lot more. :-( So is all the floating point casting So is << which overflows the width of the left operand [and this is just the undefined behaviour I've discovered in the past few days. I really do need to read and understand the whole spec] Nicholas ClarkThread Previous | Thread Next