Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.std.c > #600

The threading specs in the standard: a new catastrophe

From jacob navia <jacob@spamsink.net>
Newsgroups comp.std.c, comp.lang.c
Subject The threading specs in the standard: a new catastrophe
Date 2011-07-07 12:33 +0200
Organization lccwin
Message-ID <iv422a$33k$1@speranza.aioe.org> (permalink)

Cross-posted to 2 groups.

Show all headers | View raw


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.

I posted in this group on June 8th, 2009, a detailed critique of that 
library. Two years later all the original errors are there, together 
with new ones. I will repost again then, the most glaring errors with 
the hope that the committee corrects them before is too late and stops 
this whole idea.

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.

   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.


   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!

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.

    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!

    The mutex creation functions do not specify any security/ownership
    specifications either.
    Anybody can use anything. This will force all
    developers that run in a security sensitive environment to reject
    this specs. C stayed in the single user era.

    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.

3) New types are defined without any specification.
    Example:
    -------
   The "xtime" data type is defined as
   struct xtime { time_t sec; long nanoseconds; };

   What is the epoch of the "sec" member? Nobody knows. When you call
   a function using an "xtime" as argument with
   (struct xtime) {5,0}
   means:
   A)
   I call this function with a timeout of five seconds, i.e. the "sec"
   epoch starts running at the instant of function call.

   B)
    I call it with a timeout of January first 1970 and five seconds,
    i.e. since the "sec" member is a time_t and time_t variables are
    used to store CALENDAR TIMES (as per difftime specs in 7.26.2.1)
    I specify a timeout that has already expired.

   Nowhere in the standard is the "xtime" explained or further described.
   The committee supposes that it suffices to name a member "sec" for
   its meaning to be crystal clear.

   I fear that is not the case.


4) The new types aren't connected to the rest of the language.

    How do you convert an "xtime" into a character string?
    Does strftime accept the new type?
    Note that nowhere was specified that time_t shuld be in seconds
    since the creation of the language. Now, the committee decides
    that time_t is in seconds without giving any second thoughts
    to this change. There is a CLOCKS_PER_SEC macro defined in the
    standard a few pages after this specs. Is that obsolete?
    Should we divide the "sec" member by CLOCKS_PER_SECOND to
    obtain the actual seconds?

    Not a word of those problems, nothing. This would be comic
    if it weren't so sad.


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!

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. ALl errors I pointed out then are
still in the specs.

I hope this time they will listen or at least justify what they are
doing. Copy/Paste of Plauger's library docs is not enough to specify
a change to the C language, excuse me.

Back to comp.std.c | Previous | Next — Next in thread | Find similar | Unroll thread


Thread

The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 12:33 +0200
  Re: The threading specs in the standard: a new catastrophe Juha Niskanen <juniskan@paju.oulu.fi.nospam> - 2011-07-07 12:46 +0000
    Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 17:26 +0200
  Re: The threading specs in the standard: a new catastrophe Todd Carnes <toddcarnes@gmail.com> - 2011-07-07 13:12 +0000
    Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 17:11 +0200
      Re: The threading specs in the standard: a new catastrophe lawrence.jones@siemens.com - 2011-07-08 09:23 -0400
      Re: The threading specs in the standard: a new catastrophe Todd Carnes <toddcarnes@gmail.com> - 2011-07-08 15:20 +0000
  Re: The threading specs in the standard: a new catastrophe "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2011-07-07 07:36 -0700
    Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 17:09 +0200
      Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-07 18:00 +0200
        Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 18:20 +0200
  Re: The threading specs in the standard: a new catastrophe Wojtek Lerch <wojtek_l@yahoo.ca> - 2011-07-07 12:31 -0400
    Re: The threading specs in the standard: a new catastrophe Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-07-07 09:40 -0700
      Re: The threading specs in the standard: a new catastrophe Wojtek Lerch <wojtek_l@yahoo.ca> - 2011-07-07 14:42 -0400
        Re: The threading specs in the standard: a new catastrophe Chad <cdalten@gmail.com> - 2011-07-07 12:03 -0700
          Re: The threading specs in the standard: a new catastrophe Angel <angel+news@spamcop.net> - 2011-07-07 19:27 +0000
    Re: The threading specs in the standard: a new catastrophe Ian Collins <ian-news@hotmail.com> - 2011-07-08 09:14 +1200
      Re: The threading specs in the standard: a new catastrophe Wojtek Lerch <wojtek_l@yahoo.ca> - 2011-07-07 23:58 -0400
        Re: The threading specs in the standard: a new catastrophe Ian Collins <ian-news@hotmail.com> - 2011-07-08 16:24 +1200
      Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-08 12:14 +0200
        Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-10 00:02 +0200
          Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-10 14:47 +0200
            Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-11 21:05 +0200
              Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-11 22:50 +0200
                Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-11 23:56 +0200
                Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-12 07:50 +0200
                Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-16 01:14 +0200
                Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-16 10:08 +0200
                Re: The threading specs in the standard: a new catastrophe Miles Bader <miles@gnu.org> - 2011-07-18 11:11 +0900
                Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-18 21:50 +0200
                Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-19 08:36 +0200
                Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-21 11:56 +0200
                Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-22 20:31 +0200
                Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-22 21:36 +0200
                Re: The threading specs in the standard: a new catastrophe Jens Gustedt <Jens.Gustedt@loria.fr> - 2011-07-23 10:50 +0200
                Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-23 20:29 +0200
                Re: The threading specs in the standard... Alexander Terekhov <terekhov@web.de> - 2011-08-03 15:50 +0200
  Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-07 23:07 +0200
    Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-07 23:32 +0200
      Re: The threading specs in the standard: a new catastrophe jameskuyper <jameskuyper@gmail.com> - 2011-07-07 15:25 -0700
        Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-07 16:12 -0700
          Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-07 22:41 -0400
          Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-08 12:47 -0700
            Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-08 13:11 -0700
              Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-08 16:56 -0700
              Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-09 23:55 +0200
                Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-09 18:40 -0700
        Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-08 01:16 +0200
          some sane words, for sure "Greg A. Woods" <woods@robohack.org> - 2011-07-07 18:33 -0700
          Re: The threading specs in the standard: a new catastrophe jameskuyper <jameskuyper@gmail.com> - 2011-07-08 08:34 -0700
            Re: The threading specs in the standard: a new catastrophe sfuerst <svfuerst@gmail.com> - 2011-07-08 10:47 -0700
              Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-09 06:57 -0400
                Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-09 13:59 +0200
                Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-09 14:45 +0200
                Re: The threading specs in the standard: a new catastrophe "Chris M. Thomasson" <cristom@charter.net> - 2011-07-10 15:47 -0700
                Re: The threading specs in the standard: a new catastrophe Alexander Terekhov <terekhov@web.de> - 2011-07-11 13:38 +0200
                Re: The threading specs in the standard: a new catastrophe Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-07-11 16:12 +0300
      Re: The threading specs in the standard: a new catastrophe "MikeP" <mp011011@some.org> - 2011-07-07 23:32 -0500
      Re: The threading specs in the standard: a new catastrophe lawrence.jones@siemens.com - 2011-07-08 10:09 -0400
        Re: The threading specs in the standard: a new catastrophe Shao Miller <sha0.miller@gmail.com> - 2011-07-08 10:31 -0400
  Re: The threading specs in the standard: a new catastrophe Tim Rentsch <txr@alumni.caltech.edu> - 2011-07-07 14:32 -0700
  Re: The threading specs in the standard: a new catastrophe Shao Miller <sha0.miller@gmail.com> - 2011-07-08 00:38 -0400
  Re: The threading specs in the standard: a new catastrophe Ian Collins <ian-news@hotmail.com> - 2011-07-08 17:10 +1200
    Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-08 07:46 -0400
      Re: The threading specs in the standard: a new catastrophe Ian Collins <ian-news@hotmail.com> - 2011-07-08 23:52 +1200
        Re: The threading specs in the standard: a new catastrophe James Kuyper <jameskuyper@verizon.net> - 2011-07-08 08:23 -0400
          Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-08 14:54 +0200
          Re: The threading specs in the standard: a new catastrophe Ian Collins <ian-news@hotmail.com> - 2011-07-09 08:26 +1200
        Re: The threading specs in the standard: a new catastrophe Seebs <usenet-nospam@seebs.net> - 2011-07-08 14:47 +0000
  Re: The threading specs in the standard: a new catastrophe Juha Niskanen <juniskan@paju.oulu.fi.nospam> - 2011-07-08 07:52 +0000
    Re: The threading specs in the standard: a new catastrophe jacob navia <jacob@spamsink.net> - 2011-07-09 14:23 +0200
    Re: The threading specs in the standard: a new catastrophe Marcin Grzegorczyk <mgrzegor@poczta.onet.pl> - 2011-07-10 00:59 +0200
      Re: The threading specs in the standard: a new catastrophe Keith Thompson <kst-u@mib.org> - 2011-07-09 19:05 -0700

csiph-web