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