Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
tss_create/tss_delete
112 views
Skip to first unread message
jacob navia
Apr 15, 2012, 5:25:07 PM4/15/12
to
The specifications of this function are really wonderful.
> 7.24.6.1 The tss_createfunction
Synopsis
> int tss_create(tss_t *key, tss_dtor_t dtor);
> Description
> The tss_create function creates a thread-specific storage pointer with destructor dtor, which may be null.
> Returns
> If the tss_create function is successful, it sets the thread-specific storage pointed to by key to a value
that uniquely identifies the newly created pointer and returns
thrd_success; otherwise, thrd_error is returned
and the thread-specific storage pointed to by key is set to an undefined
value.
GREAT!
So, the tss_create function should arrange for calling a "destructor".
Since in C we have always had destructors there is no need to specify
what should that function do.
It is a "destructor", but should it free the associated storage?
Or should that be the task of tss_delete?
What happens if the "destructor" calls tss_delete() ?
There is no way to know since the "destructor" RETURNS NO RESULT
(it is prototyped as void(*)(void *) ).
There is no specification either when and in which context this function
should be called.
Should be called when tss_delete is called?
Should it be called when the thread exits even if there wasn't any call
to tss_delete?
If tss_delete is called should the "destructor" be called anyway when
the thread exits?
Those are small details that each compiler vendor will fill as it wishes
since they aren't specified anywhere.
The result is that the user can't use those functions at all. Each
compiler will interpret those vague specs as it wishes.
I warned specifically about this in several postings in this newsgroup,
the last one in July last year. I wrote:
<quote>
The committee thinks apparently that the term "destructors" is
common in C so that doesn't need any definition or explanation of what
that should be in the context of the C language. The term doesn't even
appear in the index nor is explained anywhere.
<end quote>
Now, the standard is published with the specs UNTOUCHED. They did NOT
correct ANY of those bugs.
Now, can anyone here answer the questions above?
Thanks in advance.
jacob
P.S. Obviously you can't count on your "destructor" function being
called since the integer constant
TSS_DTOR_ITERATIONS
rules how many times destructors are called. Since there isn't any
MINIMUM value a conforming implementation can decide a value of 1 should
be OK and call a single destructor. Anyway since for each tss storage
variable a separate variable is needed you can just hope that
TSS_DTOR_ITERATIONS is big!
What happens if tss_delete calls a destructor automatically?
Should tss_delete fail if TSS_DTOR_ITERATIONS count is too big?
AHH excuse me tss_delete CAN'T FAIL since it returns NO VALUE. (void)
Well, good luck!
> 7.24.6.1 The tss_createfunction
Synopsis
> int tss_create(tss_t *key, tss_dtor_t dtor);
> Description
> The tss_create function creates a thread-specific storage pointer with destructor dtor, which may be null.
> Returns
> If the tss_create function is successful, it sets the thread-specific storage pointed to by key to a value
that uniquely identifies the newly created pointer and returns
thrd_success; otherwise, thrd_error is returned
and the thread-specific storage pointed to by key is set to an undefined
value.
GREAT!
So, the tss_create function should arrange for calling a "destructor".
Since in C we have always had destructors there is no need to specify
what should that function do.
It is a "destructor", but should it free the associated storage?
Or should that be the task of tss_delete?
What happens if the "destructor" calls tss_delete() ?
There is no way to know since the "destructor" RETURNS NO RESULT
(it is prototyped as void(*)(void *) ).
There is no specification either when and in which context this function
should be called.
Should be called when tss_delete is called?
Should it be called when the thread exits even if there wasn't any call
to tss_delete?
If tss_delete is called should the "destructor" be called anyway when
the thread exits?
Those are small details that each compiler vendor will fill as it wishes
since they aren't specified anywhere.
The result is that the user can't use those functions at all. Each
compiler will interpret those vague specs as it wishes.
I warned specifically about this in several postings in this newsgroup,
the last one in July last year. I wrote:
<quote>
The committee thinks apparently that the term "destructors" is
common in C so that doesn't need any definition or explanation of what
that should be in the context of the C language. The term doesn't even
appear in the index nor is explained anywhere.
<end quote>
Now, the standard is published with the specs UNTOUCHED. They did NOT
correct ANY of those bugs.
Now, can anyone here answer the questions above?
Thanks in advance.
jacob
P.S. Obviously you can't count on your "destructor" function being
called since the integer constant
TSS_DTOR_ITERATIONS
rules how many times destructors are called. Since there isn't any
MINIMUM value a conforming implementation can decide a value of 1 should
be OK and call a single destructor. Anyway since for each tss storage
variable a separate variable is needed you can just hope that
TSS_DTOR_ITERATIONS is big!
What happens if tss_delete calls a destructor automatically?
Should tss_delete fail if TSS_DTOR_ITERATIONS count is too big?
AHH excuse me tss_delete CAN'T FAIL since it returns NO VALUE. (void)
Well, good luck!
Jens Gustedt
Apr 15, 2012, 7:17:35 PM4/15/12
to
Am 04/15/2012 11:25 PM, schrieb jacob navia:
> So, the tss_create function should arrange for calling a "destructor".
> Since in C we have always had destructors there is no need to specify
> what should that function do.
>
> It is a "destructor", but should it free the associated storage?
no
> So, the tss_create function should arrange for calling a "destructor".
> Since in C we have always had destructors there is no need to specify
> what should that function do.
>
> It is a "destructor", but should it free the associated storage?
> Or should that be the task of tss_delete?
since the storage is always allocated (or just identified) by the
application through tss_set, the thread system by itself should never
touch the associated space. In particular nothing forbids to pass a
pointer to a static object as a parameter to tss_set.
> What happens if the "destructor" calls tss_delete() ?
tss_delete with the same key
> There is no way to know since the "destructor" RETURNS NO RESULT
> (it is prototyped as void(*)(void *) ).
>
> There is no specification either when and in which context this function
> should be called.
could be in order.
> Should be called when tss_delete is called?
*be* free) this could destroy some object to which a living thread is
refering to.
> Should it be called when the thread exits even if there wasn't any call
> to tss_delete?
each time (which is an operation that concerns all threads) before the
action could be triggered for an individual thread makes not much
sense. (Meaning that this should be clarified.)
> If tss_delete is called should the "destructor" be called anyway when
> the thread exits?
tss_delete, there can't be any trace of what the destructor would be.
> Those are small details that each compiler vendor will fill as it wishes
> since they aren't specified anywhere.
it. When I implemented the C11 threads model on top of pthread, I
didn't find that one the difficult part.
> I warned specifically about this in several postings in this newsgroup,
apparently July was to late, I think, the adoption procedure already
had been engaged, I guess.
To be constructive, would you mind to file a formal defect report (or
perhaps several)? Or contact me directly, and we cook something together?
> P.S. Obviously you can't count on your "destructor" function being
> called since the integer constant
>
> TSS_DTOR_ITERATIONS
>
> rules how many times destructors are called. Since there isn't any
> MINIMUM value a conforming implementation can decide a value of 1 should
> be OK and call a single destructor. Anyway since for each tss storage
> variable a separate variable is needed you can just hope that
> TSS_DTOR_ITERATIONS is big!
"how many times destructors are called"
"how many destructors are called"
The idea of this constant, as far as I understand it, is the
following. At the moment a thread terminates, for *all* keys for which
this thread has a value the destructor function is called. Now these
destructor functions may themselves use tss_set to set other tss
values. So after the first set of destructors is called, there might
be a new set of keys with values for this thread. So this procedure of
calling destructors is iterated.
TSS_DTOR_ITERATIONS binds the number of these iterations. From that
naming one can also deduce that for each key that has a value the
destructor will be called at least once.
Again I agree that the wording of all of that is suboptimal. The POSIX
pthread_key_t from which this whole interface is copied has a much
better and unambiguous wording which should just have been copied.
Jens
jacob navia
Apr 16, 2012, 4:25:20 AM4/16/12
to
Le 16/04/12 01:17, Jens Gustedt a écrit :
MANY people could think that that was "the thing to do" in the destructor...
>> There is no way to know since the "destructor" RETURNS NO RESULT
>> (it is prototyped as void(*)(void *) ).
>>
>> There is no specification either when and in which context this function
>> should be called.
>
> I think it is clear what the intention is. But some clarifying words
> could be in order.
>
>> Should be called when tss_delete is called?
>
> Probably not. Since the destructor functions might call free (or just
> *be* free) this could destroy some object to which a living thread is
> refering to.
>
Some implementations could store the address of that destructor in the
data storage space used by the thread specific storage. They would be
forced to call the destructor when that storage space is destroyed...
In any case it would be a reasonable behavior for somebody reading the
standard text.
>> Should it be called when the thread exits even if there wasn't any call
>> to tss_delete?
>
> yes. The "key" is a global resource. Expecting tss_delete to be called
> each time (which is an operation that concerns all threads) before the
> action could be triggered for an individual thread makes not much
> sense. (Meaning that this should be clarified.)
>
>> If tss_delete is called should the "destructor" be called anyway when
>> the thread exits?
>
> No. since "all resources" for the key itself have to be freed by
> tss_delete, there can't be any trace of what the destructor would be.
>
Another implementation could store all destructors in a table (or linked
list) and call them as the thread exits. Now, since some
calls to tss_delete coud have been done, a SIGSEGV ensues with 100% chance.
The basic problem is that the standard specifications describe TWO
mechanisms for destroying the association: tss_delete and a destructor
WITHOUT specifying the interactions between them at all.
Destructors in C++ are called automatically when an object goes out of
scope. C DOES NOT HAVE such a mechanism so it MUST be specified when
the "destructors" are called!!!
>> Those are small details that each compiler vendor will fill as it wishes
>> since they aren't specified anywhere.
>
> There are certainly some ambiguities, but not as bad as you put
> it. When I implemented the C11 threads model on top of pthread, I
> didn't find that one the difficult part.
>
>> I warned specifically about this in several postings in this newsgroup,
>> the last one in July last year. I wrote: ...
>
> apparently July was to late, I think, the adoption procedure already
> had been engaged, I guess.
>
The post in July was a complaint that my EARLIER POST in 2010 wasn't
acknowledged at all. I repeated the same arguments AGAIN.
> To be constructive, would you mind to file a formal defect report (or
> perhaps several)? Or contact me directly, and we cook something together?
>
>> P.S. Obviously you can't count on your "destructor" function being
>> called since the integer constant
>>
>> TSS_DTOR_ITERATIONS
>>
>> rules how many times destructors are called. Since there isn't any
>> MINIMUM value a conforming implementation can decide a value of 1 should
>> be OK and call a single destructor. Anyway since for each tss storage
>> variable a separate variable is needed you can just hope that
>> TSS_DTOR_ITERATIONS is big!
>
> I think here you have just a language problem. This says
>
> "how many times destructors are called"
>
> and not
>
> "how many destructors are called"
>
True, this could be a language problem. I understood that each time a
destructor is called some counter is increased since the name
"DTOR_ITERATIONS"
seemed to speak about the iterations calling destructors.
> The idea of this constant, as far as I understand it, is the
> following. At the moment a thread terminates, for *all* keys for which
> this thread has a value the destructor function is called. Now these
> destructor functions may themselves use tss_set to set other tss
> values. So after the first set of destructors is called, there might
> be a new set of keys with values for this thread. So this procedure of
> calling destructors is iterated.
Yes, that is a possibility but I can't understand why you would call
tss_set in a function that is called when a thread TERMINATES...
>
> TSS_DTOR_ITERATIONS binds the number of these iterations. From that
> naming one can also deduce that for each key that has a value the
> destructor will be called at least once.
>
> Again I agree that the wording of all of that is suboptimal. The POSIX
> pthread_key_t from which this whole interface is copied has a much
> better and unambiguous wording which should just have been copied.
>
The committee should have adopted the pthreads standard AS IS, without
modifying anything. Now they have the announced catastrophe.
Anyway, I started trying to figure out what to do to implement that
stuff but it is impossible. Each time I start trying to figure out what
those functions should do I have dozens of unanswered questions like this...
> Am 04/15/2012 11:25 PM, schrieb jacob navia:
>> So, the tss_create function should arrange for calling a "destructor".
>> Since in C we have always had destructors there is no need to specify
>> what should that function do.
>>
>> It is a "destructor", but should it free the associated storage?
>
> no
>
>> Or should that be the task of tss_delete?
>
> depends on the specific model that the application wants to implement
>
> since the storage is always allocated (or just identified) by the
> application through tss_set, the thread system by itself should never
> touch the associated space. In particular nothing forbids to pass a
> pointer to a static object as a parameter to tss_set.
>
>> What happens if the "destructor" calls tss_delete() ?
>
> good point, there should be interdiction of that, at leas for calling
> tss_delete with the same key
>
There aren't any restrictions in the standard text...
>> So, the tss_create function should arrange for calling a "destructor".
>> Since in C we have always had destructors there is no need to specify
>> what should that function do.
>>
>> It is a "destructor", but should it free the associated storage?
>
> no
>
>> Or should that be the task of tss_delete?
>
> depends on the specific model that the application wants to implement
>
> since the storage is always allocated (or just identified) by the
> application through tss_set, the thread system by itself should never
> touch the associated space. In particular nothing forbids to pass a
> pointer to a static object as a parameter to tss_set.
>
>> What happens if the "destructor" calls tss_delete() ?
>
> good point, there should be interdiction of that, at leas for calling
> tss_delete with the same key
>
MANY people could think that that was "the thing to do" in the destructor...
>> There is no way to know since the "destructor" RETURNS NO RESULT
>> (it is prototyped as void(*)(void *) ).
>>
>> There is no specification either when and in which context this function
>> should be called.
>
> I think it is clear what the intention is. But some clarifying words
> could be in order.
>
>> Should be called when tss_delete is called?
>
> Probably not. Since the destructor functions might call free (or just
> *be* free) this could destroy some object to which a living thread is
> refering to.
>
data storage space used by the thread specific storage. They would be
forced to call the destructor when that storage space is destroyed...
In any case it would be a reasonable behavior for somebody reading the
standard text.
>> Should it be called when the thread exits even if there wasn't any call
>> to tss_delete?
>
> yes. The "key" is a global resource. Expecting tss_delete to be called
> each time (which is an operation that concerns all threads) before the
> action could be triggered for an individual thread makes not much
> sense. (Meaning that this should be clarified.)
>
>> If tss_delete is called should the "destructor" be called anyway when
>> the thread exits?
>
> No. since "all resources" for the key itself have to be freed by
> tss_delete, there can't be any trace of what the destructor would be.
>
list) and call them as the thread exits. Now, since some
calls to tss_delete coud have been done, a SIGSEGV ensues with 100% chance.
The basic problem is that the standard specifications describe TWO
mechanisms for destroying the association: tss_delete and a destructor
WITHOUT specifying the interactions between them at all.
Destructors in C++ are called automatically when an object goes out of
scope. C DOES NOT HAVE such a mechanism so it MUST be specified when
the "destructors" are called!!!
>> Those are small details that each compiler vendor will fill as it wishes
>> since they aren't specified anywhere.
>
> There are certainly some ambiguities, but not as bad as you put
> it. When I implemented the C11 threads model on top of pthread, I
> didn't find that one the difficult part.
>
>> I warned specifically about this in several postings in this newsgroup,
>> the last one in July last year. I wrote: ...
>
> apparently July was to late, I think, the adoption procedure already
> had been engaged, I guess.
>
acknowledged at all. I repeated the same arguments AGAIN.
> To be constructive, would you mind to file a formal defect report (or
> perhaps several)? Or contact me directly, and we cook something together?
>
>> P.S. Obviously you can't count on your "destructor" function being
>> called since the integer constant
>>
>> TSS_DTOR_ITERATIONS
>>
>> rules how many times destructors are called. Since there isn't any
>> MINIMUM value a conforming implementation can decide a value of 1 should
>> be OK and call a single destructor. Anyway since for each tss storage
>> variable a separate variable is needed you can just hope that
>> TSS_DTOR_ITERATIONS is big!
>
> I think here you have just a language problem. This says
>
> "how many times destructors are called"
>
> and not
>
> "how many destructors are called"
>
destructor is called some counter is increased since the name
"DTOR_ITERATIONS"
seemed to speak about the iterations calling destructors.
> The idea of this constant, as far as I understand it, is the
> following. At the moment a thread terminates, for *all* keys for which
> this thread has a value the destructor function is called. Now these
> destructor functions may themselves use tss_set to set other tss
> values. So after the first set of destructors is called, there might
> be a new set of keys with values for this thread. So this procedure of
> calling destructors is iterated.
tss_set in a function that is called when a thread TERMINATES...
>
> TSS_DTOR_ITERATIONS binds the number of these iterations. From that
> naming one can also deduce that for each key that has a value the
> destructor will be called at least once.
>
> Again I agree that the wording of all of that is suboptimal. The POSIX
> pthread_key_t from which this whole interface is copied has a much
> better and unambiguous wording which should just have been copied.
>
modifying anything. Now they have the announced catastrophe.
Anyway, I started trying to figure out what to do to implement that
stuff but it is impossible. Each time I start trying to figure out what
those functions should do I have dozens of unanswered questions like this...
Jens Gustedt
Apr 16, 2012, 12:46:40 PM4/16/12
to
Am 04/16/2012 10:25 AM, schrieb jacob navia:
> Le 16/04/12 01:17, Jens Gustedt a écrit :
>> Am 04/15/2012 11:25 PM, schrieb jacob navia:
>>> Should be called when tss_delete is called?
>>
>> Probably not. Since the destructor functions might call free (or just
>> *be* free) this could destroy some object to which a living thread is
>> refering to.
>>
>
> Some implementations could store the address of that destructor in the
> data storage space used by the thread specific storage.
I am not sure that I understand. It can't store the pointer to the
> Le 16/04/12 01:17, Jens Gustedt a écrit :
>> Am 04/15/2012 11:25 PM, schrieb jacob navia:
>>> Should be called when tss_delete is called?
>>
>> Probably not. Since the destructor functions might call free (or just
>> *be* free) this could destroy some object to which a living thread is
>> refering to.
>>
>
> Some implementations could store the address of that destructor in the
> data storage space used by the thread specific storage.
function in the object that is pointed to and set by tss_set, since
that object is completely "owned" by the application. It has type
void*, can be allocated with malloc or be static storage.
> They would be
> forced to call the destructor when that storage space is
> destroyed...
thread-specific storage identified by key."
That is all that is mentioned. For me "resources used by the
thread-specific storage" means "resources that are used to implement
the thread-specific storage" and not "thread-specific resources that
are handled through the key". (I hope I make this distinction clear.)
Generally a function in the standard is not allowed to do more than
what is described, in particular it is not allowed to perform
operations on any object that is not explicitly mentioned in the
description. By that it *mustn't* call the destructor for any of the
threads.
> In any case it would be a reasonable behavior for somebody reading the
> standard text.
> Another implementation could store all destructors in a table (or linked
> list) and call them as the thread exits. Now, since some
> calls to tss_delete coud have been done, a SIGSEGV ensues with 100% chance.
way. tss_destroy has to free all resources that are related to the
adminstration of the key, I think this also concernes such table
entries or list elements.
> Destructors in C++ are called automatically when an object goes out of
> scope. C DOES NOT HAVE such a mechanism so it MUST be specified when the
> "destructors" are called!!!
clearly to call the destructor when the thread exits. As I said, I
think a good idea would be to make that explicit.
Jens
Joshua Maurice
Apr 17, 2012, 4:18:28 PM4/17/12
to
Your first complaint: The C standard uses the word "destructor", which
is icky because that's nasty C++ stuff. I suppose you're one of the
people who felt it was better to just stick to pthreads and not put
any of that threading stuff in the C standard.
http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_key_create.html
> int pthread_key_create(pthread_key_t *key, void (*destructor)(void*));
[partial quote]
An optional destructor function may be associated with each key value.
At thread exit, if a key value has a non-NULL destructor pointer, and
the thread has a non-NULL value associated with that key, the value of
the key is set to NULL, and then the function pointed to is called
with the previously associated value as its sole argument. The order
of destructor calls is unspecified if more than one destructor exists
for a thread when it exits.
[/quote]
Oh wait, the C standard just more or less copied the POSIX semantics
in this case, including the POSIX wording, including the word
"destructor".
Your second complaint: It might be that the C standard is
underspecified, or that the specification is silly and broken. If it
is underspecified, then I agree that's unfortunate, and I would look
to the pthread spec for clarification in the interim, as that's what
everyone else will probably do. If you think the spec is silly and
broken, then I ask "what is a better spec?", and I ask what do you
think about pthread compatibility?
Jens Gustedt
Apr 17, 2012, 5:26:17 PM4/17/12
to
Am 04/17/2012 10:18 PM, schrieb Joshua Maurice:
> Oh wait, the C standard just more or less copied the POSIX semantics
> in this case, including the POSIX wording, including the word
> "destructor".
No, unfortunately it has not copied enough to ensure that it has the
> Oh wait, the C standard just more or less copied the POSIX semantics
> in this case, including the POSIX wording, including the word
> "destructor".
same sematics as pthread_key_t.
> Your second complaint: It might be that the C standard is
> underspecified, or that the specification is silly and broken. If it
> is underspecified, then I agree that's unfortunate, and I would look
> to the pthread spec for clarification in the interim, as that's what
> everyone else will probably do.
implement different semantics.
I have just written something up that could perhaps be the start of a
defect report
(https://gustedt.wordpress.com/2012/04/17/c11-defects-underspecification-of-tss_t/)
Jens
jacob navia
Apr 17, 2012, 7:06:20 PM4/17/12
to
Le 17/04/12 22:18, Joshua Maurice a écrit :
I said that in C++ that word is well DEFINED: a destructor is called on
an object that goes out of scope automatically. Everyone understands
that in the context of C++. In C, however, there is NO such a thing, so
you MUST specify WHEN that constructor is called. The pthread standard
then, specifies exactly what that word means. The C standard does NOT
specify AT ALL what that word means.
I raised this problem in 2010, in a detailed critique of the then
proposed thread specs.
The problem wasn't solved, so I repeated this same complaint in 2011 in
this group. Now the PUBLISHED standard has the same problem since they
did NOT specify what do they mean with that. You can say that I should
read the pthread standard but nowhere is that specified.
The POSIX standard uses the C standard but does it EXPLICITELY. Nowhere
in the C standard there is a reference to the pthread standard. Besides,
they did NOT copied the pthread standard, they copied the docs of the
library of Mr Plauger, a committee member that owns the company that
produced that library. I have pointed out this several times already.
> I suppose you're one of the
> people who felt it was better to just stick to pthreads and not put
> any of that threading stuff in the C standard.
>
I said already in my 2011 message that the C standard committee has
neither the material means nor the competenece required to produce a new
thread specification. The subject of my message was called
A NEW CATASTROPHE
The catastrophe is now here. All this specs will keep us busy for years
to come, wasting our time in refining a "new and improved" thread
specification that nobody will use.
> Your second complaint: It might be that the C standard is
> underspecified, or that the specification is silly and broken. If it
> is underspecified, then I agree that's unfortunate, and I would look
> to the pthread spec for clarification in the interim, as that's what
> everyone else will probably do.
1) Nowhere it is written in the C standard that we should refer to the
pthread standard...
2) The C standard should be fully specified, clear and complete. It is not.
> If you think the spec is silly and
> broken, then I ask "what is a better spec?", and I ask what do you
> think about pthread compatibility?
I think that the C standards group has neither the competence nor the
means to produce a new thread spec!!!
Microsoft produced a thread specs and implemented it, but they have
incredible MORE means than this committee. The pthreads standard was
developed in a time frame of years and years of collective efforts by
thousands of dedicated developers that refined slowly the specs.
To try to do the equivalent work with a few people somewhere in the C
committee is completely impossible. We are all wasting our time here.
It is not too late to take out this chapter from the standard. If it was
possible to take out essential parts of C99 10 years after the standard
publication, it is possible to take out this thread stuff a few months
after publication since nobody has implemented that.
> Your first complaint: The C standard uses the word "destructor", which
> is icky because that's nasty C++ stuff.
NO.
> is icky because that's nasty C++ stuff.
I said that in C++ that word is well DEFINED: a destructor is called on
an object that goes out of scope automatically. Everyone understands
that in the context of C++. In C, however, there is NO such a thing, so
you MUST specify WHEN that constructor is called. The pthread standard
then, specifies exactly what that word means. The C standard does NOT
specify AT ALL what that word means.
I raised this problem in 2010, in a detailed critique of the then
proposed thread specs.
The problem wasn't solved, so I repeated this same complaint in 2011 in
this group. Now the PUBLISHED standard has the same problem since they
did NOT specify what do they mean with that. You can say that I should
read the pthread standard but nowhere is that specified.
The POSIX standard uses the C standard but does it EXPLICITELY. Nowhere
in the C standard there is a reference to the pthread standard. Besides,
they did NOT copied the pthread standard, they copied the docs of the
library of Mr Plauger, a committee member that owns the company that
produced that library. I have pointed out this several times already.
> I suppose you're one of the
> people who felt it was better to just stick to pthreads and not put
> any of that threading stuff in the C standard.
>
neither the material means nor the competenece required to produce a new
thread specification. The subject of my message was called
A NEW CATASTROPHE
The catastrophe is now here. All this specs will keep us busy for years
to come, wasting our time in refining a "new and improved" thread
specification that nobody will use.
> Your second complaint: It might be that the C standard is
> underspecified, or that the specification is silly and broken. If it
> is underspecified, then I agree that's unfortunate, and I would look
> to the pthread spec for clarification in the interim, as that's what
> everyone else will probably do.
pthread standard...
2) The C standard should be fully specified, clear and complete. It is not.
> If you think the spec is silly and
> broken, then I ask "what is a better spec?", and I ask what do you
> think about pthread compatibility?
means to produce a new thread spec!!!
Microsoft produced a thread specs and implemented it, but they have
incredible MORE means than this committee. The pthreads standard was
developed in a time frame of years and years of collective efforts by
thousands of dedicated developers that refined slowly the specs.
To try to do the equivalent work with a few people somewhere in the C
committee is completely impossible. We are all wasting our time here.
It is not too late to take out this chapter from the standard. If it was
possible to take out essential parts of C99 10 years after the standard
publication, it is possible to take out this thread stuff a few months
after publication since nobody has implemented that.
jacob navia
Apr 17, 2012, 7:13:29 PM4/17/12
to
Le 17/04/12 23:26, Jens Gustedt a écrit :
It is a standard that exists (and is already DEBUGGED after all this
years of use!)
>> Your second complaint: It might be that the C standard is
>> underspecified, or that the specification is silly and broken. If it
>> is underspecified, then I agree that's unfortunate, and I would look
>> to the pthread spec for clarification in the interim, as that's what
>> everyone else will probably do.
>
> cross fingers that they do and don't come with silly exuses to
> implement different semantics.
>
That is the root problem. Since the specs are so vague that you can
understand anything from them each implementation will differ from the
others!
> I have just written something up that could perhaps be the start of a
> defect report
> (https://gustedt.wordpress.com/2012/04/17/c11-defects-underspecification-of-tss_t/)
>
That is a good start, but probably there are dozens of similar problems
in those specs! We will work and work to refine them and in the BEST
case we will have a competing standard against Microsoft and pthreads.
How can the small C committee win in a battle against such heavyweights?
This is pure nonsense.
jacob
> Am 04/17/2012 10:18 PM, schrieb Joshua Maurice:
>> Oh wait, the C standard just more or less copied the POSIX semantics
>> in this case, including the POSIX wording, including the word
>> "destructor".
>
> No, unfortunately it has not copied enough to ensure that it has the
> same sematics as pthread_key_t.
>
WHY didn't they adopt the pthread standard?
>> Oh wait, the C standard just more or less copied the POSIX semantics
>> in this case, including the POSIX wording, including the word
>> "destructor".
>
> No, unfortunately it has not copied enough to ensure that it has the
> same sematics as pthread_key_t.
>
It is a standard that exists (and is already DEBUGGED after all this
years of use!)
>> Your second complaint: It might be that the C standard is
>> underspecified, or that the specification is silly and broken. If it
>> is underspecified, then I agree that's unfortunate, and I would look
>> to the pthread spec for clarification in the interim, as that's what
>> everyone else will probably do.
>
> cross fingers that they do and don't come with silly exuses to
> implement different semantics.
>
understand anything from them each implementation will differ from the
others!
> I have just written something up that could perhaps be the start of a
> defect report
> (https://gustedt.wordpress.com/2012/04/17/c11-defects-underspecification-of-tss_t/)
>
in those specs! We will work and work to refine them and in the BEST
case we will have a competing standard against Microsoft and pthreads.
How can the small C committee win in a battle against such heavyweights?
This is pure nonsense.
jacob
Jens Gustedt
Apr 18, 2012, 2:43:52 AM4/18/12
to
Am 04/18/2012 01:06 AM, schrieb jacob navia:
> 1) Nowhere it is written in the C standard that we should refer to the
> pthread standard...
> 2) The C standard should be fully specified, clear and complete.
> It is not.
I agree on all three points.
> 1) Nowhere it is written in the C standard that we should refer to the
> pthread standard...
> 2) The C standard should be fully specified, clear and complete.
> It is not.
> It is not too late to take out this chapter from the standard. If it was
> possible to take out essential parts of C99 10 years after the standard
> publication, it is possible to take out this thread stuff a few months
> after publication since nobody has implemented that.
I don't think that this is possible. I view the main contribution of
the new standard in the specification of the atomic operations. This
was a missing piece that *must* be part of the language specification,
and that finally puts the language in sync with a feature and capacity
that is present on all modern CPUs. (One probably can find, and I
think you already did, Jacob, defects in that part, too.)
Atomic operations need a specification of a thread model. The
committee could have used the POSIX thread specification, but it seems
that this would not have been consensual because it contains / assumes
certain things that other thread models (MS, I guess) don't have or
that seemed too difficult to implement from scratch. So they were
seeking for a minimal intersection between the main competitors. The
result is what we see now a cooked down version of pthread, with many
defects in the specification.
This thread model with reduced expressiveness in certain aspects also
fits better directly into C than pthread does. The fact that thread
functions just return an int error code is better in line with the
execution model. Also it is much simpler with much less knobs to tune
(all that attribute stuff in pthread is omitted) but that simplicity
may well be an advantage for its adoption by users and implementors.
Jens
Wojtek Lerch
Apr 18, 2012, 7:56:29 AM4/18/12
to
On 17/04/2012 4:18 PM, Joshua Maurice wrote:
> http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_key_create.html
>> int pthread_key_create(pthread_key_t *key, void (*destructor)(void*));
> [partial quote]
> An optional destructor function may be associated with each key value.
> At thread exit, if a key value has a non-NULL destructor pointer, and
> the thread has a non-NULL value associated with that key, the value of
> the key is set to NULL, and then the function pointed to is called
> with the previously associated value as its sole argument. The order
> of destructor calls is unspecified if more than one destructor exists
> for a thread when it exits.
> [/quote]
The C standard doesn't contain anything resembling the above, does it?
> http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_key_create.html
>> int pthread_key_create(pthread_key_t *key, void (*destructor)(void*));
> [partial quote]
> An optional destructor function may be associated with each key value.
> At thread exit, if a key value has a non-NULL destructor pointer, and
> the thread has a non-NULL value associated with that key, the value of
> the key is set to NULL, and then the function pointed to is called
> with the previously associated value as its sole argument. The order
> of destructor calls is unspecified if more than one destructor exists
> for a thread when it exits.
> [/quote]
> Oh wait, the C standard just more or less copied the POSIX semantics
> in this case, including the POSIX wording, including the word
> "destructor".
"destructor" in the C standard, and only one one of them actually talks
about the behaviour of destructors -- unfortunately, without going into
details. All it says is that TSS_DTOR_ITERATIONS specifies the maximum
number of times that destructors will be called when a thread
terminates. I have not found any mention of whether destructors might
be called an any other time, what arguments they're called with, or even
whether the TSS_DTOR_ITERATIONS limit specifies the total number of
destructor calls per program, per thread, per destructor, or perhaps
something else.
(In case it makes a difference, I was using N1570 instead of the
official standard, but my understanding is that it doesn't, does it?)
> Your second complaint: It might be that the C standard is
> underspecified, or that the specification is silly and broken. If it
> is underspecified, then I agree that's unfortunate, and I would look
> to the pthread spec for clarification in the interim, as that's what
> everyone else will probably do. If you think the spec is silly and
> broken, then I ask "what is a better spec?", and I ask what do you
> think about pthread compatibility?
the specification is pretty much non-existent. The only way to guess
the intent is by noticing the resemblance to POSIX, and ignoring the
fact that C decided to drop the word "key" and refer to the keys as
"thread-specific storage pointers", as if they where thread-specific.
(I guess that can easily count as silly and broken.)
jacob navia
Apr 18, 2012, 9:39:55 AM4/18/12
to
Le 18/04/12 13:56, Wojtek Lerch a écrit :
standard instead of relying in Dinkum's library.
Now we are faced with the huge task of debugging a complete new
threading standard, what will take us at least several years of efforts.
The C standards committee has neither the material means (budget) nor
the intellectual competences for doing such an enormous task.
>> Oh wait, the C standard just more or less copied the POSIX semantics
>> in this case, including the POSIX wording, including the word
>> "destructor".
>
> Which POSIX wording? I have counted three places that use the word
> "destructor" in the C standard, and only one one of them actually talks
> about the behaviour of destructors -- unfortunately, without going into
> details.
I reported that in a detailed bug report on 2010. Then I repeated it in
much more stronger terms in 2011 (July) complaining that my 2010 bug
reports went unnoticed. Now the bugs are published as a standard.
How can be they so isolated from the community?
What is the point of the publication processes initiating a "discussion"
phase if the bug reports go to /dev/null ???
All it says is that TSS_DTOR_ITERATIONS specifies the maximum
> number of times that destructors will be called when a thread
> terminates. I have not found any mention of whether destructors might be
> called an any other time, what arguments they're called with, or even
> whether the TSS_DTOR_ITERATIONS limit specifies the total number of
> destructor calls per program, per thread, per destructor, or perhaps
> something else.
I understood that was the total number of destructors called but Mr
Gustedt (see his message in this same thread) thinks that is the total
number of calls to a *single* destructor is called when a thread
terminates. Anyway there is no way to know until the committee decides
to fill the gaps. This is ridiculous.
>
> (In case it makes a difference, I was using N1570 instead of the
> official standard, but my understanding is that it doesn't, does it?)
>
>> Your second complaint: It might be that the C standard is
>> underspecified, or that the specification is silly and broken. If it
>> is underspecified, then I agree that's unfortunate, and I would look
>> to the pthread spec for clarification in the interim, as that's what
>> everyone else will probably do. If you think the spec is silly and
>> broken, then I ask "what is a better spec?", and I ask what do you
>> think about pthread compatibility?
>
> What specification? The problem, when it comes to destructors, is that
> the specification is pretty much non-existent. The only way to guess the
> intent is by noticing the resemblance to POSIX, and ignoring the fact
> that C decided to drop the word "key" and refer to the keys as
> "thread-specific storage pointers", as if they where thread-specific. (I
> guess that can easily count as silly and broken.)
Well, since I work mainly in windows I am not that familiar with
pthreads, not because I have anything against pthreads but just because
I did not study it. Then, I did not see any similarities between
pthreads specs and C standard specs.
What I am 100% sure is that the whole specification of the C standard
is a cut and paste copy of the specifications of the thread library of
the company of Mr Plauger, one of the committee members.
I would have nothing against that either if those specs were correct
but they aren't. They are just a specific library documentation mainly
for C++ users. To directly use that in the C standard is quite strange
really.
Other bugs that I signaled but made their way into the standard are:
The types are:
(1)
cnd_t
which is a complete object type that holds an identifier for a condition
variable;
thrd_t
which is a complete object type that holds an identifier for a thread;
The whole standard text uses the word "identifier" with a WELL DEFINED
MEANING. In the threads chapter however, this word is used with a
different meaning without any explanation of what they are talking
about: what "identifier" ???
Probably this is a numeric value that is used to identify a condition or
a thread, but nowhere is that specified.
(2)
The time functions that use an "xtime". When I want to have a timeout of
(say) 5 seconds, should I:
A: do an xtime_get to get the current time
B: Add 5 seconds to the current time
C: Pass that to the timeout functions
OR
A: pass (xtime){5,0} to the timeout functions?
I.e. do the timeout functions use an xtime that should contain just the
timeout or the current time + the timeout?
This is NOT SPECIFIED!!!
The ONLY specs about the epoch that the timeout uses is that xtime_get
uses a "base" argument that MUST be "TIME_UTC".
The "TIME_UTC" symbol is NOWHERE described and nobody can know what it
should contain; what its type is or what it should be. IT APPEARS
NOWHERE ELSE. The only sentence where this appears is in the docs of the
xtime_get function.
Synopsis
#include <threads.h>
int xtime_get(xtime *xt, int base);
Description
The xtime_get function sets the xtime object pointed to by xt to hold
the current time based on the time base base.
Returns
If the xtime_get function is successful it returns the nonzero value
base, which must be TIME_UTC; otherwise, it returns zero.
Why does xtime_get have a 2nd argument that MUST be always the same
value (TIME_UTC whatever that is)? If they wanted to leave place for
future expansions they should have said so.
What is that TIME_UTC?
Yes, since UTC *could* mean Universal Time Coordinates it *COULD* be
that the timeout should be in UTC coordinates. This would mean that
timeouts longer than 24 hours are forbidden since UTC coordinates just
describe the offset to add/subtract for getting the local time...
> On 17/04/2012 4:18 PM, Joshua Maurice wrote:
>> http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_key_create.html
>>
>>> int pthread_key_create(pthread_key_t *key, void (*destructor)(void*));
>> [partial quote]
>> An optional destructor function may be associated with each key value.
>> At thread exit, if a key value has a non-NULL destructor pointer, and
>> the thread has a non-NULL value associated with that key, the value of
>> the key is set to NULL, and then the function pointed to is called
>> with the previously associated value as its sole argument. The order
>> of destructor calls is unspecified if more than one destructor exists
>> for a thread when it exits.
>> [/quote]
>
> The C standard doesn't contain anything resembling the above, does it?
>
Yes, and that is the problem... They SHOULD have copied the pthread
>> http://pubs.opengroup.org/onlinepubs/009604499/functions/pthread_key_create.html
>>
>>> int pthread_key_create(pthread_key_t *key, void (*destructor)(void*));
>> [partial quote]
>> An optional destructor function may be associated with each key value.
>> At thread exit, if a key value has a non-NULL destructor pointer, and
>> the thread has a non-NULL value associated with that key, the value of
>> the key is set to NULL, and then the function pointed to is called
>> with the previously associated value as its sole argument. The order
>> of destructor calls is unspecified if more than one destructor exists
>> for a thread when it exits.
>> [/quote]
>
> The C standard doesn't contain anything resembling the above, does it?
>
standard instead of relying in Dinkum's library.
Now we are faced with the huge task of debugging a complete new
threading standard, what will take us at least several years of efforts.
The C standards committee has neither the material means (budget) nor
the intellectual competences for doing such an enormous task.
>> Oh wait, the C standard just more or less copied the POSIX semantics
>> in this case, including the POSIX wording, including the word
>> "destructor".
>
> Which POSIX wording? I have counted three places that use the word
> "destructor" in the C standard, and only one one of them actually talks
> about the behaviour of destructors -- unfortunately, without going into
> details.
much more stronger terms in 2011 (July) complaining that my 2010 bug
reports went unnoticed. Now the bugs are published as a standard.
How can be they so isolated from the community?
What is the point of the publication processes initiating a "discussion"
phase if the bug reports go to /dev/null ???
All it says is that TSS_DTOR_ITERATIONS specifies the maximum
> number of times that destructors will be called when a thread
> terminates. I have not found any mention of whether destructors might be
> called an any other time, what arguments they're called with, or even
> whether the TSS_DTOR_ITERATIONS limit specifies the total number of
> destructor calls per program, per thread, per destructor, or perhaps
> something else.
Gustedt (see his message in this same thread) thinks that is the total
number of calls to a *single* destructor is called when a thread
terminates. Anyway there is no way to know until the committee decides
to fill the gaps. This is ridiculous.
>
> (In case it makes a difference, I was using N1570 instead of the
> official standard, but my understanding is that it doesn't, does it?)
>
>> Your second complaint: It might be that the C standard is
>> underspecified, or that the specification is silly and broken. If it
>> is underspecified, then I agree that's unfortunate, and I would look
>> to the pthread spec for clarification in the interim, as that's what
>> everyone else will probably do. If you think the spec is silly and
>> broken, then I ask "what is a better spec?", and I ask what do you
>> think about pthread compatibility?
>
> What specification? The problem, when it comes to destructors, is that
> the specification is pretty much non-existent. The only way to guess the
> intent is by noticing the resemblance to POSIX, and ignoring the fact
> that C decided to drop the word "key" and refer to the keys as
> "thread-specific storage pointers", as if they where thread-specific. (I
> guess that can easily count as silly and broken.)
pthreads, not because I have anything against pthreads but just because
I did not study it. Then, I did not see any similarities between
pthreads specs and C standard specs.
What I am 100% sure is that the whole specification of the C standard
is a cut and paste copy of the specifications of the thread library of
the company of Mr Plauger, one of the committee members.
I would have nothing against that either if those specs were correct
but they aren't. They are just a specific library documentation mainly
for C++ users. To directly use that in the C standard is quite strange
really.
Other bugs that I signaled but made their way into the standard are:
The types are:
(1)
cnd_t
which is a complete object type that holds an identifier for a condition
variable;
thrd_t
which is a complete object type that holds an identifier for a thread;
The whole standard text uses the word "identifier" with a WELL DEFINED
MEANING. In the threads chapter however, this word is used with a
different meaning without any explanation of what they are talking
about: what "identifier" ???
Probably this is a numeric value that is used to identify a condition or
a thread, but nowhere is that specified.
(2)
The time functions that use an "xtime". When I want to have a timeout of
(say) 5 seconds, should I:
A: do an xtime_get to get the current time
B: Add 5 seconds to the current time
C: Pass that to the timeout functions
OR
A: pass (xtime){5,0} to the timeout functions?
I.e. do the timeout functions use an xtime that should contain just the
timeout or the current time + the timeout?
This is NOT SPECIFIED!!!
The ONLY specs about the epoch that the timeout uses is that xtime_get
uses a "base" argument that MUST be "TIME_UTC".
The "TIME_UTC" symbol is NOWHERE described and nobody can know what it
should contain; what its type is or what it should be. IT APPEARS
NOWHERE ELSE. The only sentence where this appears is in the docs of the
xtime_get function.
Synopsis
#include <threads.h>
int xtime_get(xtime *xt, int base);
Description
The xtime_get function sets the xtime object pointed to by xt to hold
the current time based on the time base base.
Returns
If the xtime_get function is successful it returns the nonzero value
base, which must be TIME_UTC; otherwise, it returns zero.
Why does xtime_get have a 2nd argument that MUST be always the same
value (TIME_UTC whatever that is)? If they wanted to leave place for
future expansions they should have said so.
What is that TIME_UTC?
Yes, since UTC *could* mean Universal Time Coordinates it *COULD* be
that the timeout should be in UTC coordinates. This would mean that
timeouts longer than 24 hours are forbidden since UTC coordinates just
describe the offset to add/subtract for getting the local time...
jacob navia
Apr 18, 2012, 9:46:06 AM4/18/12
to
Sorry I should have re-read the last paragraphs.
They are very confusing. I will rewrite them and post them again in a
new thread.
They are very confusing. I will rewrite them and post them again in a
new thread.
Jens Gustedt
Apr 18, 2012, 10:17:05 AM4/18/12
to
Am 04/18/2012 03:39 PM, schrieb jacob navia:
> (2) The time functions that use an "xtime" ...
no they don't.
For once you are much too pessimistic, Jacob :)
The version that made it to the standard is much more consistent in
what is concerned "time". There is no mention of xtime at all in n1570
and for example TIME_UTC is defined. I think that your complaints
concerning this made it to the standard, at least partially.
Jens
> (2) The time functions that use an "xtime" ...
no they don't.
For once you are much too pessimistic, Jacob :)
The version that made it to the standard is much more consistent in
what is concerned "time". There is no mention of xtime at all in n1570
and for example TIME_UTC is defined. I think that your complaints
concerning this made it to the standard, at least partially.
Jens
Wojtek Lerch
Apr 18, 2012, 10:43:27 AM4/18/12
to
On 17/04/2012 7:13 PM, jacob navia wrote:
> Le 17/04/12 23:26, Jens Gustedt a écrit :
>> Am 04/17/2012 10:18 PM, schrieb Joshua Maurice:
>>> Oh wait, the C standard just more or less copied the POSIX semantics
>>> in this case, including the POSIX wording, including the word
>>> "destructor".
>>
>> No, unfortunately it has not copied enough to ensure that it has the
>> same sematics as pthread_key_t.
>>
>
> WHY didn't they adopt the pthread standard?
I can think of a few good reasons:
> Le 17/04/12 23:26, Jens Gustedt a écrit :
>> Am 04/17/2012 10:18 PM, schrieb Joshua Maurice:
>>> Oh wait, the C standard just more or less copied the POSIX semantics
>>> in this case, including the POSIX wording, including the word
>>> "destructor".
>>
>> No, unfortunately it has not copied enough to ensure that it has the
>> same sematics as pthread_key_t.
>>
>
> WHY didn't they adopt the pthread standard?
* There's no such thing as the pthread standard. Just taking the parts
of POSIX that talk about threads would not be sufficient -- the full
text of the POSIX standard has many dependencies between threads and the
rest of POSIX functionality that doesn't exist in ISO C, and removing
them would take a substantial amount of cleaning up.
* Presumably the goal was to reduce the functionality to a subset that
could be easily implemented outside of the POSIX/Unix world.
* Something that doesn't scream POSIX might be easier to get through the
approval process.
Keith Thompson
Apr 18, 2012, 2:56:39 PM4/18/12
to
jacob navia <ja...@spamsink.net> writes:
[...]
a good way to get these problems addressed.
[...]
> The ONLY specs about the epoch that the timeout uses is that xtime_get
> uses a "base" argument that MUST be "TIME_UTC".
>
> The "TIME_UTC" symbol is NOWHERE described and nobody can know what it
> should contain; what its type is or what it should be. IT APPEARS
> NOWHERE ELSE. The only sentence where this appears is in the docs of the
> xtime_get function.
Which draft are you using? N1570 defines TIME_UTC in 7.17.1 (<time.h>)
as a macro "which expands to an integer constant greater than 0 that
designates the UTC time base", and does not contain the string "xtime".
[...]
--
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"
[...]
> The C standards committee has neither the material means (budget) nor
> the intellectual competences for doing such an enormous task.
I suggest that disparaging comments about the committee members are not
> the intellectual competences for doing such an enormous task.
a good way to get these problems addressed.
[...]
> The ONLY specs about the epoch that the timeout uses is that xtime_get
> uses a "base" argument that MUST be "TIME_UTC".
>
> The "TIME_UTC" symbol is NOWHERE described and nobody can know what it
> should contain; what its type is or what it should be. IT APPEARS
> NOWHERE ELSE. The only sentence where this appears is in the docs of the
> xtime_get function.
as a macro "which expands to an integer constant greater than 0 that
designates the UTC time base", and does not contain the string "xtime".
[...]
--
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"
0 new messages