Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.std.c,comp.lang.c Subject: Re: The threading specs in the standard: a new catastrophe Date: Fri, 08 Jul 2011 17:10:11 +1200 Lines: 112 Message-ID: <97nhr2F6tbU3@mid.individual.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 21jNkjaJg0MxMQwoGC0m2QRLnukwSkgkAPFlejfammcZVgTSwt Cancel-Lock: sha1:vSMykp15MvCpJ+gVpcowfCoJ/p4= User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.4 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.std.c:643 comp.lang.c:7941 On 07/ 7/11 10:33 PM, jacob navia wrote: > The committee has decided, for reasons unknown to me (there is no > explanation why is this necessary anywhere) to go on with the flawed > Dinkum library specs and proclaim that library as the new standard specs > for the whole language, what will surely please Plauger but leaves the > rest of us with a pile of errors. > > 1) The specs use concepts from C++ without furnishing the slightest > explanation of how those concepts should be understood within the C > language. > > Examples: > -------- > 7.25.1.3 > TSS_DTOR_ITERATIONS > which expands to an integer constant expression representing the > maximum number of times that destructors will be called when a > thread terminates. This term is quite clear in the latest draft, see 7.26.1.4. > 7.25.1.4 > cnd_t > which is a complete object type that holds an identifier for a > condition variable; > > How can a type "hold an identifier" ??? The committee defines in > 6.4.2.1.2 an identifier as a sequence of letters that designates > one or more entities. > Now, we have the opposite: a type holds an identifier and nowhere > is explained what that should mean! The type is an implementation detail, just like pthread_t is in POSIX. > 2) The proposed functions are absurd. > > Take, for instance, nothing less than the thread creation function > thrd_create: > > int thrd_create(thrd_t *thr, thrd_start_t func,void *arg); > > As you can see, there are *no arguments that can be passed to the > underlying operating system* to further specify the newly created > thread. (The "args" arument is an argument for the thread). > > The pthreads standard (POSIX) proposes an "attributes" argument. The > Microsoft threads propose a "security attributes" and a set of flags > that further specify the newly created thread. The C API proposes > NOTHING so it is impossible to use. In many (most) cases, the default values get passed in pthreads at least. > Since there is no way to specify the attributes, this function MUST > use the default attributes that are NOWHERE specified. This means > that two compiler systems could very well produce two different sets > of attributes to be passed to the underlying thread creation > functions so that we would have a differnt behavior for the same > source compiled in the same machine. This is completely ridiculous! Agreed, there should be something there, even if it says they are implementation defined! > The mutex creation functions do not specify any security/ownership > specifications either. Neither does POSIX. > The specifications are completely unusable in many other functions: > For instance: > The thrd_detach function tells the operating system to dispose of > any resources allocated to the thread identified by thr when that > thread terminates. > > That's new to me. The OS should free all memory allocated by the > thread? Close all files? This is highly system dependent and > many systems could very well not do the cleanup until the process > that created those ressources stops. Not *by* the thread *to* the thread. > 3) New types are defined without any specification. > Example: > ------- > The "xtime" data type is defined as > struct xtime { time_t sec; long nanoseconds; }; Fixed (gone) in current draft. > 5) Error analysis is very difficult. > > The proposed functions return the enum value "thrd_error" if > SOMETHING goes wrong. Impossible to know WHAT did go wrong since > nowhere is specified if errno should have a value set or how > to figure out WHAT HAPPENED!!! There is NO WAY that the running > program can communicate the reasons of failure so that we are > left in the dark as to why each error happens. The Microsoft API > specifies GetLastError() and pthreads have errno and other > mechanisms to further speicify what kind of error happened. This > specs ignore all that. It doesn't work, now go figure what happens > during HOURS of debugging! At least in the current draft, the returns are no more or less informative than pthread_create (which does not set errno). > I am repeating here in an expanded form the critique that I wrote > in comp.std.c in a message on June 8th 2009. There was no answer then, > and there has been no change since. But there have, you quoted form an out of date draft! -- Ian Collins