On Sat, Oct 26, 2002 at 02:31:56PM -0400, Dossy wrote:

> Anything that calls into your third-party library, grab a shared mutex
> before and unlock it after.  Basically, make sure that there is only ONE
> thread at any given point in time interacting with your third party
> library.  Performance might suffer, but if that's what it takes to make

Oh, I did that long ago.  Doesn't seem to be sufficient, I still get
those segfaults in _smalloc.

On shared libraries, I think that if I have two processes both loading
the same .so, then that .so is shared between them, and if the library
is not thread safe I'll be hosed, even if all access to the library
within each process is serialized via mutexes?  Is that true?  Or is
there some magic which makes a non-thread-safe .so safe to use from
multiple concurrent processes?

Is there any way to tell a process to load it's own independent
run-time copy of a .so, so that I don't have to go through the hassle
of instead statically linking in a .a library instead?

My _smalloc segfault happens even if only 1 copy of the shared library
is in use anywhere, but that problem does make me think more about
these issues...

--
Andrew Piskorski <[EMAIL PROTECTED]>
http://www.piskorski.com

Reply via email to