Changing threading semantics from init early to init before second thread

[Alexander Larsson]

On Mon, 2006-08-28 at 11:27 -0400, Havoc Pennington wrote:
> Alexander Larsson wrote:
> > Its pretty ok:
> > 
> 
> Seems sane. So the thread init would be like this, right:
> 
>   on first mutex creation
>     if threads explicitly disabled, don't init
>     else if threads already init'd, don't change anything
>     else if linux/glibc and linking to pthread, init threads
>     else if linux/glibc and not linking to pthread,
>             act as if threads had been explicitly disabled
>     else if not linux/glibc, init threads
> 
> Hmm, though what happens if a dlopen()'d module using dbus links to 
> pthread and the app does not? Are we back to the problem we were trying 
> to fix about the app needing to init threads on behalf of the module?

I dunno what happens then. Is it even allowed? I mean, I think glibc
uses "linking to libpthreads" to decide whether to do locking in
malloc() etc.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a scrappy zombie Green Beret trapped in a world he never made. She's a 
plucky goth barmaid looking for love in all the wrong places. They fight 
crime!