[Bug 1731] pthread_join() returns ESRCH if target thread already terminated

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1731

Chris Johns <chrisj at rtems.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |chrisj at rtems.org

--- Comment #3 from Chris Johns <chrisj at rtems.org> 2011-05-25 20:03:08 CDT ---
(In reply to comment #3)
> 
> According to the pthread_join() documentation, "if thread has already
> terminated, then this routine returns immediately." I read that as it should
> return success immediately.
> 

The SUSv3 also states:

  "[ESRCH]
      No thread could be found corresponding to that specified by the
      given thread ID."

If the thread has terminated we have to return this error code when we return
immediately. The SUSv3 Rational states:

 "The pthread_join() function is a convenience that has proven useful in
  multi-threaded applications. It is true that a programmer could simulate
  this function if it were not provided by passing extra state as part of the
  argument to the start_routine(). The terminating thread would set a flag
  to indicate termination and broadcast a condition that is part of that state;
  a joining thread would wait on that condition variable. While such a
  technique would allow a thread to wait on more complex conditions (for
  example, waiting for multiple threads to terminate), waiting on individual
  thread termination is considered widely useful. Also, including the
  pthread_join() function in no way precludes a programmer from coding
  such complex waits. Thus, while not a primitive, including pthread_join()
  in this volume of IEEE Std 1003.1-2001 was considered valuable."

I consider the "more complex" case in the rational an inverted version of your
case, ie "Both threads terminate on the same condition" means you broadcast to
the threads to terminate then attempt to join them. I suspect any
implementation that allows this case to work for you is only doing so due to
implementation specifics. I think you need to handle the thread termination
sequentially because you cannot be in 2 joins at once.

The idea of holding state information for a thread pasts its life does not
sound correct. It was also not clear to me how the zombie data was to be
avoided.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.