> Padraig Brady <padraig@antefacto.com> writes:
>
>
>>This breaks for the case discussed @
>>http://sources.redhat.com/ml/bug-glibc/2001-11/msg00079.html
>>I.E. if you have a multithreaded lib being linked by
>>single threaded apps (Note multithreaded lib, not just a
>>threadsafe lib (I.E. the lib calls pthread_create())).
>>
>
> That's an interesting, but very contrived, example. Can you find a
> single multi-threaded lib that uses FILE*'s shared with the
> application using it?
Well you have to deal with the general case. A single threaded
app linking against a multithreaded lib. It mightn't be just
shared FILE*'s that could cause problems.
> Linus's suggestion to add hooks to pthread_create() gets around that
> problem, anyway.
I don't think this will work as I said before current apps that
use _unlocked() functions directly manipulate the stdio structures,
hence a "new smarter locking stdio" would never get used by existing
compiled apps.
> Alternatively, the multi-threaded library could
> require any application linking to it to define _REENTRANT.
It could, but what if an existing interface (lib) is changed
from signle to multithreaded. You can't preclude this.
> After all, it's silly to talk about a 'multi-threaded' library linked
> to a 'single-threaded' application -- the application plus any
> libraries, as a whole, are either multithreaded or not. They have to
> be on the same page to deal with *any* locking issues.
>
> -- Michael
Padraig.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/