This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Ping[2]: [PATCH] Fix sporadic failure in tst-eintr1 test case
- From: Jonathan Nieder <jrnieder at gmail dot com>
- To: KOSAKI Motohiro <kosaki dot motohiro at gmail dot com>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Date: Mon, 1 Oct 2012 12:12:39 -0700
- Subject: Re: Ping[2]: [PATCH] Fix sporadic failure in tst-eintr1 test case
- References: <20120920141557.4d74155d@spoyarek><20120920144516.40d18070@spoyarek><20120924174116.11fd6b63@spoyarek><20121002000423.30e99e6a@spoyarek><CAHGf_=rQSC33ZnpGR3xwuBUEZ=1-mEOupFP=8qXyc6r_Qy7G3g@mail.gmail.com>
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.
Jonathan