Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Newsgroups | comp.std.c, comp.lang.c |
| Subject | Re: The threading specs in the standard: a new catastrophe |
| Date | 2011-07-08 00:38 -0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <iv61gp$faf$1@dont-email.me> (permalink) |
| References | <iv422a$33k$1@speranza.aioe.org> |
Cross-posted to 2 groups.
On 7/7/2011 06:33, 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.
>
Uh oh.
> 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.
>
But ought a future C Standard to cover threads _somehow_? As I
mentioned before, the sequencing model is really striking in C1X. It
has "before" and "after" (and un- and indeterminately, etc.)... Thread
discussion would seem to cover "simultaneously"! (Roughly.)
> 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.
>
Hmmm.
>
> 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!
>
Hmmm again.
> 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).
>
I wouldn't use the proposed C1X threads with such expectations. I'd use
libraries and interfaces which meet my expectations.
> 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.
>
Why, there's even "thread impersonation" in at least Windows. There're
even "fibers". So I would assume that for C1X threads, no such
considerations are portable and thus don't belong in a C Standard.
> 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!
>
Why is it ridiculous? Let's pretend for a moment that C1X (or later)
thread support gives only a minimal and mundane set of capabilities.
Something to the effect of "now my program doesn't need to follow a
strictly sequential order of execution." That seems worth having on any
platform that could support it (which itself is a concern). For
anything else, don't use C threads.
> 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.
>
I disagree. I think it's worth noting that the term "threads" might not
have a meaning of great value on its own ("_its_", Mr. J. Kuyper, not
"_it's_"!). I don't see a reason why "C threads" must encompass "POSIX
thread" details or "Windows thread" details. I _certainly_ don't see
why a developer would attempt to use "portable C threads" with security
in mind when security itself is platform-dependent!
A microwave doesn't need to worry about carrying access control lists
with Active Directory SIDs! But it might like to distract you with an
LCD dance while it monitors for temperature dangers!
> 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.
>
Such as a thread descriptor whose storage the kernel might enjoy
repossessing, perhaps.
> 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.
>
I agree that that'd seem strange, if that's what the authors' intentions
are. Not impossible, mind you. I would agree that clarification is
warranted, given your interpretation.
> 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.
>
Hmmm yet again.
>
> [...more about "time"...]
>
> 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!
>
For simple threads, a simple error might be sufficient. If an
implementation documents that their "C threads" map to some subset of
"OS threads," perhaps they'd also provide additional functions. Else,
don't try to write portable code that cares about platform-specific errors.
> 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.
>
D'oh.
> 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.
>
But wouldn't it be nice to have _some_ kind of thread support in C? I
would not appreciate a very sophisticated thread system, and would not
appreciate injecting POSIX threads into the C Standard. Please keep it
Cimple. It'd be nice to write a simple, portable program with multiple
threads of execution.
Back to comp.std.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll 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