[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [libmicrohttpd] "Failed to join a thread": Race condition when closi
Re: [libmicrohttpd] "Failed to join a thread": Race condition when closing the connection?
Fri, 2 Feb 2018 09:27:59 +0100
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
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
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.
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.
Description: OpenPGP digital signature