Subj : Re: pthreads and fork To : comp.programming.threads From : Torbjorn Lindgren Date : Sat Feb 19 2005 07:16 pm Marcin 'Qrczak' Kowalczyk wrote: >resources which are released directly by pthread_join (excluding >cleanup handlers and TLS descructors, which I know are not run). >The only way to free them, if they should be fred explicitly, is >to call pthread_join. I don't know whether calling pthread_join >on a thread which died because of fork is legal. > >Single Unix Spec should not have been silent about this. It should >either say that pthread_join must be used to free resources, or >that pthread_join must not be used, or that this interaction is not >supported at all and there is no way to prevent a memory leak (unless >the program calls exec soon, and thus the memory leak is temporary and >doesn't matter, or had only one thread, and thus there is nothing to >leak). But it ISN'T silent, it explicitly says: * fork(): "the child process may only execute async-signal safe operations until such time as one of the exec functions is called" * pthread_join(): NOT async-signal safe, IE can't be called. (copied from SUSv2, but SUSv3 appears to have the exact same wording). So it clearly outlaws it, no if or but. Basically you need to call one of the exec functions almost immediately in the child thread, because there's very little you can do with only the async-signal safe operations. >What happens with detached threads? There are only two choices here: >either their resources are properly deallocated (excluding cleanup >handlers and TLS descructors), or there is a memory leak. The standard text implies that unless the OS handles "correctly" it may leak memory, but if so there's nothing you can do... *If* it leaks it's likely a *QOI* issue, not a "conformance issue" per se. This means if it does leak you'd have to try to get your vendor to improve their implementation so that it doesn't. >Making pthread_join allowed would be logical, because data associated >with threads which have already terminated is probably not touched by You have two standard compliant choices: * Don't call pthread_join() and hope that the implementors didn't something stupid. This the standard assumption EVERYWHERE anyway... * Avoid the entire issue by not using fork() after you've created threads. My preference would be to avoid the entire issue, NOT because possible memory leaks but because it's a rather dark corner where I wouldn't be the least susprised to find crash/hang bugs even for correctly written code on some platforms. The standard way to avoid this entirely is to fork() of a helper process before creating the first thread. When you need to start another program you send commands to the helper over the pipe()... http://www.unix.org/version3/ http://www.unix.org/version2/ >fork at all. Since pthread_join on Linux doesn't crash, and it returns >0 if and only if it executes an internal call of __free_tcb(), maybe >the situation is supported at least on Linux. Maybe if I check at >configure time whether pthread_join on such thread doesn't crash and >succeeds, I can use it. Are there systems where it works sometimes >but is not generally safe? You're firmly in "nasal demon territory" if you do this with regard to POSIX/SUS, and personally I doubt anyone is likely to DEFINE it for their system (as opposed to "seems to work a particular way on version x.y.z without corrupting anything, but could change at any time, even with totally unrelated minor patches). So, unless you can guarantee that nothing will ever be upgraded (even minor security upgrades) AND someone has examined the code to make sure nothing bad could happen (like long-term corruption which causes crashes hours or days later!) I'd strongly suggest that you follow SUS, via either of the two options mentioned above. .