Andrew Chernow wrote:
> Tom Lane wrote:
> > Andrew Chernow <ac@esilo.com> writes:
> >> The attached patch replaces the win32 mutex calls with critical
> >> section calls. The change will not affect the behavior of the
> >> windows pthread_xxx functions.
> >
> > Why have you defined the lock/unlock functions as willing to fall
> > through silently if handed a null pointer? I think a crash in
> > such a case is what we *want*. Silently not locking is surely
> > not very safe.
> >
> > regards, tom lane
> >
>
> Yeah, both naughty.
>
> These functions were not implemented to spec. These pthread
> functions are all supposed to return an int (which is an errno
> value). I was trying not to change the existing prototypes ...
> should I? I can return EINVAL if something is NULL and ENOMEM if the
> malloc fails ... or just dump core.
>
> If you like the return value idea, I can make all occurances of
> pthread_xxx check the return value.
Getting these emails in the wrong order for some reason :-(
Yes, actually checking the return values from these functions in libpq
seems like a good idea to me. ISTM that we already have the case where
we can fall through silently when failing to lock, and that should be
fixed.
It looks like the internal API of pgthreadlock_t needs to be changed as
well in this case, because it can currently only reaturn void. But - it
also seems we are not actually *using* it anywhere. Perhaps that part
of the API should simply be removed?
//Magnus
