Re: Library interoperability problem

On Tue, Nov 18, 2003 at 09:10:26PM -0800, Mike Abbott wrote:
> > Compatibility with libpthread.
> 
> Gene has volunteered to look into this again.  I'm hoping it's something
> simple like copying a magic value from the primordial stack into every
> state thread's stack at creation time, but Gene fears the worst.

He's right to fear the worst; they have a whole struct at the bottom of the
stack (pthread_descr).... and some of those fields have to be consistent with 
all the other state thread stacks, such as p_errno (by value, not pointer).

Ie: your solution is impossible.

I don't think that a pthread specific hack in libst will solve this.
Not to mention, this sort of coupling would make libst brittle.

My personal take on this is that library developers need an alternative.
Something like a 'meta-threading' library which provides mutexes.

When finally linked to a real thread-model, the stubbed methods become calls
to the real threading library. If there is no threading, they are no-ops.

I have a library which already tries to do this called libwthread (for weak
threads) which has the same ABI as pthreads for mutexes and conditions.
However, it is not finished, and I had hope that maybe people could come up
with a better idea. 

The idea was that people could just relink libraries against libwthread and
it would 'just work': noops without threads and do the right thing with
threads. As I wrote it I discovered how tied to pthreads ABI compatibility
would force it to become. Hence, I think another approach which is only API
compatible might be better.

eg: #define pthread_mutex_create wthread_mutex_create ...

-- 
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/