Library interoperability problem (was: current status?)

On Tue, Nov 18, 2003 at 08:35:51AM -0800, Mike Abbott wrote:
> > Just wondering what the current status of State Threads is.
> 
> Funny you should ask.  Gene and I talked recently about releasing a new
> version.  I think the result of the conversation was that Gene had to
> recover his computer from its disk crash first then he would forward to
> me all his changes.  Then I'll make a new version.

Although I know I am just a lowly peon, there is something I think 
REALLY needs to be addressed before the next release:

Compatibility with libpthread.

I don't mean both threading models being used simultaneously, but I do mean
at least link-level compatibility. Right now, many useful libraries which
have nothing thread specific are linked to libpthread.

For example, libxml is not multithreaded; however, it links to libpthreads
so that it can protect global datastructures which would cause it to
segfault under a pthread multi-threaded application.

Most of gnome >= 2.2 also links to pthreads for the same reason. In fact,
nearly all reasonably mature libraries in the open source world get linked
to pthreads for one reason or another.

For those not aware, if you link (in)directly to libpthread, the moment a
non-primordial state thread runs nearly any method, it will die.

I have looked into this problem to some depth; here is what I know:

Pthread and glibc are tightly coupled.
Glibc makes several calls to weak symbols which are provided by pthread.
As long as pthread is not linked, these methods are all NULL and libc does
not end up actually calling them.
Once pthread is linked to an application, whether by a dependent library or
directly, its methods get called regardless of whether or not it is used.
Even something as simple as 'int j = errno;' will end up calling pthreads.
Pthreads on linux looks for thread information at the bottom of the stack.
In state threads, this information is not present.
This means the program segfaults.

This presents a problem for a would-be libst user: If they use libst
they are unable to use a large number of high quality libraries. I like
st a lot, but several times now this choice has forced me to use pthreads.

The scenario where I first ran into this was by linking to libxml.
My program segfaulted immediately after a state thread checked errno.

I find it extremely unlikely that glibc/pthreads will change ABI
compatibility for us. This change could not be backwards compatible 
on their part since they use some inlined macros which get compiled 
into applications. Naturally, this sucks for us, but there it is.

I hope I have convinced you that the current state of affairs is not
acceptable. So now we need to talk solutions or work-arounds.

I have some ideas about how to deal with this, but I'd like to hear what
others think first.

-- 
Wesley W. Terpstra <[email protected]>


-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/