Hi, # I had meant to send this to the list as well. It's a week later now # and I have already requested merged the pu/ branch mentioned below.
I'm no pthread buff either, but Jens-U. Mozdzen writes: > Hi *, > > quoting Allan: >> >> I'm no expert either, but your basic analysis seems correct- once you >> have returned from pthread_join(), the thread is gone, and its return >> value has been popped. > > that's indeed the way it works. Upon return of pthread_join(), the > thread is *gone*... unless it returns with a non-zero rc. > >> I suppose it is possible that the pthread_join >> could fail in a way that might leave the thread running, perhaps >> because of a deadlock? In that case I suppose we could call >> pthread_detatch only if there is an error? > > Other reasons to for pthread_join() to fail would be an already > pending pthread_join() in a different thread. > > It's not necessary/valid to call pthread_detach() on all error cases - > i.e. in case of ESRCH, there is no thread with that id. Calling > pthread_detach() then will only return ESRCH itself, the same holds > true for EINVAL. The only valid, documented return value of pthread_join() where calling pthread_detach() might make sense is EDEADLK. However, I am not sure what the effect is of detaching the calling thread. Perhaps adding a check for that makes sense. I've pushed a proposed upgrade. If that looks okay, please merge. The changes can be found at https://gitlab.com/sane-project/backends/commits/pu/dont-detach-after-join > What doesn't fit the problem description is that calling > pthread_detach() for an already terminated thread results in a segv. > I'd rather have expected a return of ESRCH in such case. The only > unspecified result (per man page) is for calling pthread_detach() > multiple times on the same thread. Might this be the case here? > > quoting Gerhard >> I wonder why it took 11 years to spot that ;) > > If it is a case of calling pthread_detach() multiple times, it may be > because the code got compiled for a new platform. "undefined results" > include causes a segv :D. Or maybe the pthread lib contains a bug, > i.e. segfaulting on detaching a no longer existing thread, rather than > returning ESRCH, or some race condition. > > Regards, > Jens Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 Support Free Software Support the Free Software Foundation https://my.fsf.org/donate https://my.fsf.org/join -- sane-devel mailing list: sane-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to sane-devel-requ...@lists.alioth.debian.org