On Wed, 24 Nov 2004, Nathan J. Williams wrote:

> "Johnny C. Lam" <jlam@NetBSD.org> writes:
>
> > This is the solution I am currently implementing for pkgsrc.  I need
> > two issues to be clarified before I start modifying packages:
> >
> > (1) I have a shared library that dlopens shared modules that may be
> >     potentially link with "-pthread".  Should this shared library be
> >     linked with "-pthread"?
>
> No.
>
> > (2) I have an application that links against this above shared library.
> >     Does this application need to be linked with "-pthread"?
>
> Yes.
>
> As before, I would counsel caution as to whether the modules being
> opened should, in fact, be linked against libpthread. This essentially
> becomes "do they call pthread_create()"? For the applications that
> have been listed earlier in this thread, is it possible to enumerate
> the modules that link against libpthread and check them for this
> property? I fear that a module is being linked against libpthread to
> satisfy the module's attempts at thread-safety in the presence of a
> threaded app, but the app isn't threaded either.

Why only pthread_create()? I mean, how can a module be written
so that it can satisfy thread-safety in the presence of a
threaded app, without the module directly using pthread functions
such as mutexes etc.

Say a module has some global list, and functions add_to_list()
and remove_from_list(). How can the module be written so that
it magically is thread safe when the app is threaded?  To work
with threaded apps correctly, it clearly needs to use
pthread mutexes, and that in turn requires that the module is
linked against pthread.