Re: [libmicrohttpd] "Failed to join a thread": Race condition when closing the connection?

[Christian Grothoff]

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