Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

at_thread_exit

36 views
Skip to first unread message

jacob navia

unread,
Apr 15, 2012, 1:37:35 PM4/15/12
to
The new standard has added _Exit() and quick_exit(), and a new list of
functions to be called (different from the atexit() function we already
know).

OK, but what about "at_thread_exit()" ???

This is very important, since many programs rely on being called when a
thread exits to be able to do a cleanup and erase the thread ID from
internal tables.

For instance a GC needs to know when a thread exits to be able to take
out its stack from the list of valid places where it has to search for
pointers. Failure to do so means an access violation.

I was unable to find anything equivalent in the new standard. This can
have two reasons:

1) I have forgotten (or missed) some paragraph, even if I searched the
relevant parts of the new standard.

2) The committee forgot that function.

Thanks in advance for your time.

jacob

Marc

unread,
Apr 15, 2012, 2:17:02 PM4/15/12
to
jacob navia wrote:

> The new standard has added _Exit() and quick_exit(), and a new list of
> functions to be called (different from the atexit() function we already
> know).
>
> OK, but what about "at_thread_exit()" ???

You can pass a destructor argument to tss_create (a very C++ way of
doing things...).

jacob navia

unread,
Apr 15, 2012, 4:04:51 PM4/15/12
to
Le 15/04/12 20:17, Marc a écrit :
But that means that one of the big advantages of the at*.* functions is
gone since you have to know the exit function at the start of the thread!

You can't do:
if (errorcount > 5)
at_exit_thread(ReportErrors);
else if warningcount > 5)
at_exit_thread(ReportWarnings);

Of course, it is possible to add this function but it would have been
better to have a standard name.



Keith Thompson

unread,
Apr 15, 2012, 6:15:13 PM4/15/12
to
Surely the function itself can determine what it needs to do when it's
called. The thread-specific storage created by the tss_create call can
hold whatever information is needed to determine what to do when the
thread terminates and the destructor is called.

--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

jacob navia

unread,
Apr 15, 2012, 6:19:19 PM4/15/12
to
Le 16/04/12 00:15, Keith Thompson a écrit :
> Surely the function itself can determine what it needs to do when it's
> called. The thread-specific storage created by the tss_create call can
> hold whatever information is needed to determine what to do when the
> thread terminates and the destructor is called.
>

The destructor is NOT called when tss_delete is called?

What makes you think that the "destructor" is called when the thread exits?

Please, not your opinion but a specification in the standard. As far as
I see there are no specifications at all when this "destructor" should
be called.

Jens Gustedt

unread,
Apr 15, 2012, 6:34:18 PM4/15/12
to
Am 04/15/2012 10:04 PM, schrieb jacob navia:
> Le 15/04/12 20:17, Marc a écrit :
>> jacob navia wrote:
>>
>>> The new standard has added _Exit() and quick_exit(), and a new list of
>>> functions to be called (different from the atexit() function we already
>>> know).
>>>
>>> OK, but what about "at_thread_exit()" ???
>>
>> You can pass a destructor argument to tss_create (a very C++ way of
>> doing things...).
> But that means that one of the big advantages of the at*.* functions is
> gone since you have to know the exit function at the start of the thread!

No, you can determine the specific function that is to be called from
the contents of the key. Something like

struct destructor {
tss_dtor_t func;
}

void call_destructor(void* dest) {
if (dest) {
tss_dtor_t d = dest;
tss_dtor_t func = d->func;
func();
}
}

tss_key_t key;
tss_create(&key, call_destructor);
...

static struct destructor dest = { .func = my_favorite_func };
tss_set(&key, &dest);


Obviously you can extend this scheme by making this a linked list of
such function pointers that are called in FIFO, LIFO or whatever
order.

But I agree that having the specification of such a thing in the
application code is suboptimal. A generic solution as for at_exit
would have been preferable.

Jens


Keith Thompson

unread,
Apr 16, 2012, 3:49:54 AM4/16/12
to
N1570 7.26.1p3 says that TSS_DTOR_ITERATIONS "expands to an integer
constant expression representing the maximum number of times that
destructors will be called when a thread terminates".

That doesn't seem to me to be very clear. I haven't studied that
section closely, so I could well be missing something.
0 new messages