|
From: Jeremy F. <je...@go...> - 2002-10-20 20:53:44
|
On Sun, 2002-10-20 at 13:33, Julian Seward wrote:
How about just link in our libpthread.so under all circumstances? Surely
the magic hacks it does for some functions (select, poll, etc) are harmless
for single-threaded programs, just a little inefficient? Is there any
advantage to the added complication of switching behaviours depending on
whether or not a second thread has been created? All else being equal
I prefer to avoid complexity like that.
It leaks the pthread names into programs which didn't ask for
libpthread. But that's pretty likely anyway, given the number of
libraries which pull in libpthread for you.
Also, some of libpthread's substitutions may not be functionally
identical to the real functions, so it would be nice to avoid
introducing that complexity unless it is necessary (I don't think that's
the case at the moment, but it is true for the non-blocking open, which
is impossible to emulate exactly).
So I don't have a strong objection to always bringing in libpthread, but
I do think we should just use the standard libc implementations unless
we actually need the threaded versions.
J
|