On Wed, Dec 02, 2020 at 10:58:14AM +0100, Sebastien Marie wrote:
> On Wed, Dec 02, 2020 at 08:29:15AM +0100, Otto Moerbeek wrote:
> >
> > Anyway, here's a man page diff
>
> another man page diff.
>
>
> Zig upstream said that OpenBSD man page for pthread_join() is a bit
> misleading (but they will look to follow the posix way).
>
> pthread_join man page citation:
> > When a pthread_join() returns successfully, the target thread has been
> > terminated.
>
> I agree with them that it isn't perfectly accurate, even if POSIX
> is saying the same.
>
> When pthread_join() returns successfully, it means that the
> synchronization point between pthread_exit() and pthread_join() has
> been passed, but the target thread could have not called __threxit()
> at this point.
>
> Is a more nuanced statement is desirable ? Or adding a CAVEAT section
> to precise it ?
>
>
> diff 671d91b2e74d462e4a819e4e39e69d9570a7a2b6 /usr/src
> blob - feb059b39d2fb0a0261feaefb821277e612f0c5d
> file + lib/libpthread/man/pthread_join.3
> --- lib/libpthread/man/pthread_join.3
> +++ lib/libpthread/man/pthread_join.3
> @@ -61,7 +61,7 @@ by the terminating thread is stored in the location re
> .Fa value_ptr .
> When a
> .Fn pthread_join
> -returns successfully, the target thread has been terminated.
> +returns successfully, the target thread is about to terminate.
> The results of multiple simultaneous calls to
> .Fn pthread_join
> specifying the same target thread are undefined.
It's hard to come up with the proper formulation. the terminating
thread has passed the "point of no return" in a way. Maybe
..., the target thread has called pthread_exit(), but note that its
resources might not have been cleaned up yet.
-Otto
