This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Ping[2]: [PATCH] Fix sporadic failure in tst-eintr1 test case


On Mon, Oct 1, 2012 at 3:12 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> KOSAKI Motohiro wrote:
>
>> I have a question. Do any standard require pthread_join() ensure to
>> reduce NPROC? I guess no.
>
> It's not clear to me, but my guess is also no.
>
> The following passage seems to involve an assumption that joined
> threads would not count towards implementation limits (otherwise, why
> would it single out unjoined threads in particular?):
>
>         It is unspecified whether a thread that has exited but remains
>         unjoined counts against {PTHREAD_THREADS_MAX}.
>
> The (non-normative) rationale explains that pthread_join() could be
> emulated in a way that would be subject to the same race:
>
>         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.
> [...]
>         Thus, while not a primitive, including pthread_join() in this
>         volume of POSIX.1-2008 was considered valuable.
>
> A quick search didn't find any stronger wording in either direction.

Great.

If we are permitted condvar based implementation, this race is also
permitted IMHO. Obviously, when signaling exit state, the child thread
is not dead from point of kernel view. Temporal NPROC should be fine.


btw, lll_wait_tid() comment about CLONE_CLEARTID. But it's a typo.
real name is CLONE_CHILD_CLEARTID (see createthread.c). It would
be great if someone fix it too.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]