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.
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 -- sane-devel mailing list: [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/sane-devel Unsubscribe: Send mail with subject "unsubscribe your_password" to [email protected]
