Hi Jan-Benedict, This is very strange, the loop should not fix this, as pthread_join should simply block (not race!) until the thread is done. In fact, I generally think the right answer to ESRCH would be to die, as to me this indicates some kind of memory corruption or other severe invariant violation.
Now, given that you mentioned changes related to popen()-logic in your own code, I wonder if the change in your _application_ logic related to fork() may be interoperating badly with threads. In particular, after you fork(), all of the "other" threads will be gone, so if you fork() and then continue any MHD-interaction related to the threads spawned by MHD, that is likely to be, eh, problematic --- and may show up with an ESRCH. However, that doesn't quite explain to me why putting this in a loop with sleeps might fix it. (But I don't know enough about your code.) Regardless, the loop/sleep is a very, very wrong fix, and I strongly suspect the problem is in your code (or how you use the MHD API, in conjunction with fork()). My 2 cents. Happy hacking! Christian On 02/01/2018 06:21 PM, Jan-Benedict Glaw wrote: > Testing it a bit, I found out that pthread_join() returns 3 > (== ESRCH), which shall happen when "No thread with the ID thread > could be found." (man 3 pthread_join). I would have expected > "EINVAL thread is not a joinable thread." though... > > However, putting the pthread_join() or MHD_join_thread_() into a > small loop with a few msec delay in between fixed it, with an > occassional hint that it took a second try to reap the thread.
signature.asc
Description: OpenPGP digital signature
