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
