On Wed, 10 Sep 2003 12:29 pm, Bruce Momjian wrote: > --- anyway, it is probably threadsafe, but strerror isn't, so we are > dead anyway. :-)
Oh, I see. Yep, good point. Strange that strerror isn't threadsafe when everything else is... maybe Strange is OSF's middle name. > > #ifdef SOME_DEF (sorry, have to check the ECPG source on that one) > > pthread_mutex_lock(&my_mutex) > > #endif > > > > /* do stuff */ > > > > #ifdef SOME_DEF > > pthread_mutex_unlock(&my_mutex) > > #endif > > Yep. Ugly but required. Could be worse - at least creating a wrapper function keeps the aesthetically-offensive code away from most of the code, and everyone else could just call pg_gethostbyname() or whatever... > > Yeah, or you could just always use the wrapper and not try to do all the > > test in configure... doubtless less efficient, but maybe better for the > > mental health... > > True. In fact, on platforms with non-*_r functions that are > thread-safe, those locks are already done in libc anyway. The problem > is that on platforms that don't have non *_r thread-safe, and don't > have all the *_r functions, we would be adding overhead to libpq that > isn't already part of libc on that platform, and that seems wrong to me. > Double-yuck. No, correct me if I'm wrong, but the #ifdef'd code is removed by the pre-processor, so platforms without thread support would gain only the overhead of a single function call? That doesn't seem so steep. The actual copying of the structs wouldn't be needed in this case, so handle that like: #ifdef SOME_DEF /* copy structure and set return pointer to this copy /* #else /* set return pointer to global buffer */ #endif It's only a penalty for platforms with thread-safe functions called within the mutex_locked section... and if we're talking about functions like gethostbyname() (which may well be making a network call to a DNS server) I doubt the second mutex_lock would be a noticeable penalty. Making copies of structures is some penalty, that's true... I might try some timings to see how much of a penalty. Are these functions likely to see such heavy use that the additional times are a problem? > We might have to produce a libpq_r and ecpg_r (yuck) on those platforms. I beg you, stay away from this idea! Informix does this, and it isn't pretty. I have the core files to prove it. > > Ummm... replace /* do stuff /* above with a deep copy of the hostent > > struct. I'll give that a shot if you like. > > Tripple-yuck. :-) Hey, are you impugning my coding style? If so, you'll have to join the queue. :-) Do you want me to have a try at the gethostbyname() wrappers, or is it going to be a waste of time? Regards, Philip. ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match