[cpp-threads] Asynchronous Execution Issues

Alexander Terekhov alexander.terekhov at gmail.com
Mon Apr 27 19:17:10 BST 2009


On Mon, Apr 27, 2009 at 6:32 PM, Peter Dimov <pdimov at mmltd.net> wrote:
>> Does anyone see a way to get any detached_thread to safely shut down
>> without calling quick_exit()?

pthread_attr_settermnotify().

http://www.rdg.opengroup.org/austin/mailarchives/ag/msg04445.html

Thread link:

http://www.rdg.opengroup.org/austin/mailarchives/ag/thrd130.html#04396

>
> I think that, under POSIX, the only way to make sure that a thread has
> finished calling the TLS destructors and is done with its stack (this is
> important if the stack is managed by the application) is to call
> pthread_join.

http://www.rdg.opengroup.org/austin/mailarchives/ag/msg04453.html

(Quoting Butenhof.)

-----
Perhaps we could even begin to suggest that we could be seeing some
sort of consensus?

1. We need to strengthen pthread_join() to require that the joiner is
awakened after the terminating thread's resources have been
"stablized". All cleanup handlers and TSD destructors are done,
and the thread is no longer executing on its stack. If the stack
is application-managed, the application is able to free or reuse
the stack; if the stack was implementation-managed, the resources
will be available to reuse in future thread creations. (Though we
probably shouldn't try to guarantee that the stack MUST be reused
immediately.)
2. We should add pthread_timedjoin(), which would look like
pthread_join() with an additional "struct timespec*" argument
specifying the absolute system time (clock base as described in
the 1003.1d timer additions); at which the waiting thread should
give up and return with ETIMEDOUT. (For a nonblocking "poll", one
could specify a timespec of {0,0}... or we could make it a little
more convenient by allowing a NULL timespec pointer.)
-----

IIRC, there was no action taken.

regards,
alexander.



More information about the cpp-threads mailing list