Hello Barclay, recent history of this mailing list:
8 Feb 2004: I post 2 questions, 23 Feb 2004: someone posts questions, 19 Mar 2004: you post questions, in 2 or 3 weeks time someone else will post another difficult question, I hope you get the picture, 2 things you can do: pthread is layered above pth, so first study the layer file pthread.c where pthread_atfork() is implemented via a pth function. Now study the pth function and see if you can hack the source yourself, thats your only chance because I dont even know what atfork() is, Alternatively as you said unshared library is ok, use that, naive thought: I think Pth may use global variables, could this lead to probs with shared libraries or do the shared libraries have some mechanism to make the global variables reentrant? you are in the deep end, On 18-Mar-04, Barclay Osborn wrote: >Greetings, > >I didn't see a searchable archive of this list, so I'll just fire away: >I'm having some issues with pthread_atfork() when call from inside shared >objects. The basic scenario is thus: > >Environment: Redhat 7.3 x86, kernel 2.4.18, glibc 2.2.5. >A library (call it 'testlib') has been written that will be called from both >multi-threaded and multi-process applications. The architecture of these >applications is not under my control. Each thread needs it's own copy of >various data structures and to perform thread-specific initialization tasks. >In essence, the library needs to "know" when a call comes down that is the >first call of a new thread (forked or otherwise) and perform setup. > >As an example, let's boil this down to a basic case one process with one >thread forking one child. Let's call the most frequently-accessed routine >getTSD(). The outline of getTSD() is: > - use pthread_once to setup a global TSD key (pthread_key_t) that will > refer to an int*. All threads will use that key to index into their > local copy of the int*. > - get the TSD, if it's NULL, do the various initialization tasks for > the thread (such as allocated the memory the int* will point to), > otherwise, just return the TSD int*. > >I have a sample library and test application that does this available at: > http://www.redgeek.net/~barclay/pthread-test.tgz >The interesting part is that my application works if compiled as a static >archive, do it this way then, pth is quite lean so the extra overhead is not worth thinking about, >but the atfork handlers don't seem to trigger if the library is >compiled as a shared object. Debugging inside gdb w/ >multiprocess/multithread >seems a lost cause ('set follow-fork-mode child' doesn't work, at least on >x86.) > >Any help is appreciated, feel free to wget pthread-test.tgz, the code can >probably describe my setup better than text. Standard usage: untar, cd, >make. It'll build both a .a and .so version of the library, and two >executables, test-ar and test-so, each of which link with the previous, >respectively. > >Thanks for your time, >-Barclay >______________________________________________________________________ >GNU Portable Threads (Pth) http://www.gnu.org/software/pth/ >Development Site http://www.ossp.org/pkg/lib/pth/ >Distribution Files ftp://ftp.gnu.org/gnu/pth/ >Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/ >User Support Mailing List [EMAIL PROTECTED] >Automated List Manager (Majordomo) [EMAIL PROTECTED] ______________________________________________________________________ GNU Portable Threads (Pth) http://www.gnu.org/software/pth/ Development Site http://www.ossp.org/pkg/lib/pth/ Distribution Files ftp://ftp.gnu.org/gnu/pth/ Distribution Snapshots ftp://ftp.ossp.org/pkg/lib/pth/ User Support Mailing List [EMAIL PROTECTED] Automated List Manager (Majordomo) [EMAIL PROTECTED]
