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

Groups > comp.lang.c > #7823 > unrolled thread

The threading specs in the standard: a new catastrophe

Back to article view | Back to comp.lang.c

Contents

  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 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 Chad <cdalten@gmail.com> - 2011-07-07 12:55 -0700
                Re: The threading specs in the standard: a new catastrophe Angel <angel+news@spamcop.net> - 2011-07-07 20:13 +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 "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 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

Page 1 of 3  [1] 2 3  Next page →

#7823 — The threading specs in the standard: a new catastrophe

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.

[toc] | [next] | [standalone]

#7831

On 2011-07-07, jacob navia <jacob@spamsink.net> wrote:
> 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.

Hello Jacob,

Have you reviewed committee document N1570?
Wikipedia says this is the latest draft:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

I think some of your critique has been answered already. See also

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1571.pdf

where the committee "agreed in principle" to change struct xtime to
struct timespec and clarify its semantics to match POSIX more closely.
This change has been applied to N1570.

-- 
Juha Niskanen

[toc] | [prev] | [next] | [standalone]

#7832

On Thu, 07 Jul 2011 12:33:48 +0200, jacob navia wrote:

[snip]

> 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.

[snip]

I have no idea if you are right or wrong, and don't pretend to know, but 
why would anyone on the standards committee care about one person's 
postings on usenet? I doubt they read the newsgoups.

Todd

[toc] | [prev] | [next] | [standalone]

#7845

Le 07/07/11 15:12, Todd Carnes a écrit :
> On Thu, 07 Jul 2011 12:33:48 +0200, jacob navia wrote:
>
> [snip]
>
>> 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.
>
> [snip]
>
> I have no idea if you are right or wrong, and don't pretend to know, but
> why would anyone on the standards committee care about one person's
> postings on usenet? I doubt they read the newsgoups.
>
> Todd

"They do not read anything, or care about anyone."

Is that what you want to say?

Maybe you are just wrong, and they do care about what the community
thinks or proposes.

Or maybe you are right, and they live in limbo. Time will tell.

[toc] | [prev] | [next] | [standalone]

#7968

In comp.std.c jacob navia <jacob@spamsink.net> wrote:
> 
> "They do not read anything, or care about anyone."
> 
> Is that what you want to say?
> 
> Maybe you are just wrong, and they do care about what the community
> thinks or proposes.
> 
> Or maybe you are right, and they live in limbo. Time will tell.

A more accurate description is that they have quite enough to do reading
things that come in through official channels and caring about the
community they're required to care about to go looking for other things
to read or other groups to care about.
-- 
Larry Jones

My upbringing is filled with inconsistent messages. -- Calvin

[toc] | [prev] | [next] | [standalone]

#7980

On Thu, 07 Jul 2011 17:11:08 +0200, jacob navia wrote:

> "They do not read anything, or care about anyone."
> 
> Is that what you want to say?

No, more like I think they're probably too busy to worry about reading a 
bunch of newsgroups for suggestions.

Most newsgroups are high on noise & low on real content.

Todd

[toc] | [prev] | [next] | [standalone]

#7841

Another rant.

Just your point 2: C threads share memory. Since they share memory,
you can just about ignore security (there is none). For security, you
would need separate processes, and at that point it is really outside
the realm of C. So having no "attributes" for thread creation is Ok
with me. And C threads wouldn't pass "default attributes" to some
underlying system, they just behave as defined by the C standard. So
if you encounter different behavior, then either one implementation is
non-conforming, or your expectations of thread behavior are wrong.
Your comments on "thrd_detach" can only be interpreted as a deliberate
misunderstanding. Allocated memory and opened files are _not_
"resources allocated to the thread". They are allocated _by_ some
thread _to_ the whole application.

[toc] | [prev] | [next] | [standalone]

#7844

Le 07/07/11 16:36, christian.bau a écrit :
> Another rant.
>
> Just your point 2: C threads share memory. Since they share memory,
> you can just about ignore security (there is none).


Ahh, OK. Both pthreads and Microsoft allow for attributes in their
create functions. OK. They are both wrong because Mr Christian Bau
says so.

The security attributes in Microsoft's version concern the inheritance
of the newly created thread handles: are they inherited by child
processes?

You have just shown us your ignorance.

> For security, you
> would need separate processes, and at that point it is really outside
> the realm of C.

As far as I know "system()" creates a new process. But apparently you
think that is "outside the realm of C". OK then.

> So having no "attributes" for thread creation is Ok
> with me.

With you. Not with Microsoft windows or with pthreads.


> And C threads wouldn't pass "default attributes" to some
> underlying system, they just behave as defined by the C standard.

And you think they will not use the underlying operating system or
or what? The underlying OS implementations REQUIRE those parameters
so you HAVE to pass something in there.

> So
> if you encounter different behavior, then either one implementation is
> non-conforming, or your expectations of thread behavior are wrong.

The standard doesn't say if the new thread starts suspended or not,
Compiler "A" starts the thread in a suspended state, compiler "B"
starts without suspension. Which is right?

> Your comments on "thrd_detach" can only be interpreted as a deliberate
> misunderstanding. Allocated memory and opened files are _not_
> "resources allocated to the thread".

no? Then WHAT are those "ressources"?  They aren't even specified!

> They are allocated _by_ some
> thread _to_ the whole application.

Depends on the OS.

[toc] | [prev] | [next] | [standalone]

#7851

Am 07.07.2011 17:09, schrieb jacob navia:
> You have just shown us your ignorance.

I don't think that bashing on people will bring your issue forward.

>> And C threads wouldn't pass "default attributes" to some
>> underlying system, they just behave as defined by the C standard.
> 
> And you think they will not use the underlying operating system or
> or what? The underlying OS implementations REQUIRE those parameters
> so you HAVE to pass something in there.

Yes, certainly. An implementation of the C1x stuff has to provide the
right arguments to the OS implementation of threads, e.g if the the
underlying implementation is pthread, it has to set the attribute
argument properly, if the default for pthread is not conforming to
C1x. I don't see a particular difficulty in that one, it is the C1x
thrd implementation that has to provide these arguments.

You would be right in saying that this model is kind of restrictive,
allowing for only one execution model. In particular it is a pity that
it doesn't allow to start threads in a detached state.

> The standard doesn't say if the new thread starts suspended or not,
> Compiler "A" starts the thread in a suspended state, compiler "B"
> starts without suspension. Which is right?

Hm, since it doesn't define the term "suspended state" and supension
of a thread is only done via a sleep function for a limited time, I
don't really understand your issue here.

>> Your comments on "thrd_detach" can only be interpreted as a deliberate
>> misunderstanding. Allocated memory and opened files are _not_
>> "resources allocated to the thread".
> 
> no? Then WHAT are those "ressources"?  They aren't even specified!

Here, a better wording would probably be appropriate. I think
injecting the word "specific" before "resources" would already be a
good disambiguation.


Jens

[toc] | [prev] | [next] | [standalone]

#7852

Le 07/07/11 18:00, Jens Gustedt a écrit :
> Am 07.07.2011 17:09, schrieb jacob navia:
>> You have just shown us your ignorance.
>
> I don't think that bashing on people will bring your issue forward.
>

Well, he started his message with

"Another rant"

That's OK?

My tone was appropiate for his tone.


>>> And C threads wouldn't pass "default attributes" to some
>>> underlying system, they just behave as defined by the C standard.
>>
>> And you think they will not use the underlying operating system or
>> or what? The underlying OS implementations REQUIRE those parameters
>> so you HAVE to pass something in there.
>
> Yes, certainly. An implementation of the C1x stuff has to provide the
> right arguments to the OS implementation of threads, e.g if the the
> underlying implementation is pthread, it has to set the attribute
> argument properly, if the default for pthread is not conforming to
> C1x. I don't see a particular difficulty in that one, it is the C1x
> thrd implementation that has to provide these arguments.
>
> You would be right in saying that this model is kind of restrictive,
> allowing for only one execution model. In particular it is a pity that
> it doesn't allow to start threads in a detached state.
>

Are the threads visible to child processes? Microsoft requires a
"security attributes" parameter that defines if the thread is inherited
to child process or not. Compilar "A" under windows decides that the
threads aren't visible, compiler "B" decides that they are. Which is
right?

>> The standard doesn't say if the new thread starts suspended or not,
>> Compiler "A" starts the thread in a suspended state, compiler "B"
>> starts without suspension. Which is right?
>
> Hm, since it doesn't define the term "suspended state" and supension
> of a thread is only done via a sleep function for a limited time, I
> don't really understand your issue here.
>

A thread is suspended when the OS doesn't run it and doesn't schedule
it.

>>> Your comments on "thrd_detach" can only be interpreted as a deliberate
>>> misunderstanding. Allocated memory and opened files are _not_
>>> "resources allocated to the thread".
>>
>> no? Then WHAT are those "ressources"?  They aren't even specified!
>
> Here, a better wording would probably be appropriate. I think
> injecting the word "specific" before "resources" would already be a
> good disambiguation.
>

It should be clear from the specifications text what those ressources are.

[toc] | [prev] | [next] | [standalone]

#7853

On 07/07/2011 6:33 AM, jacob navia wrote:
...
> 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.

Do you find fopen() absurd and impossible to use too?  Or are file or 
stream attributes (such as the POSIX permission bits, or O_EXCL) less 
important to you than some of the thread attributes that POSIX or 
Windows have?

[toc] | [prev] | [next] | [standalone]

#7854

On Jul 7, 7:31 pm, Wojtek Lerch <wojte...@yahoo.ca> wrote:
>
> Do you find fopen() absurd and impossible to use too?  Or are file or
> stream attributes (such as the POSIX permission bits, or O_EXCL) less
> important to you than some of the thread attributes that POSIX or
> Windows have?
>
If it's the only interface to the file system, you may have problems.
For instance you can't tell the size of a file, you can't scan a
directory, you can't set read or write permissions or flag it as a
temporary. You can't lock it from other processes.

--
Visit my website
http://www.malcolmmclean.site11.com/www

[toc] | [prev] | [next] | [standalone]

#7867

On 07/07/2011 12:40 PM, Malcolm McLean wrote:
> On Jul 7, 7:31 pm, Wojtek Lerch<wojte...@yahoo.ca>  wrote:
>>
>> Do you find fopen() absurd and impossible to use too?  Or are file or
>> stream attributes (such as the POSIX permission bits, or O_EXCL) less
>> important to you than some of the thread attributes that POSIX or
>> Windows have?
>>
> If it's the only interface to the file system, you may have problems.

Or not, depending on what you're trying to do.

> For instance you can't tell the size of a file, you can't scan a
> directory, you can't set read or write permissions or flag it as a
> temporary. You can't lock it from other processes.

Right; but if you do need to do any of those things, then you can't rely 
on C99 alone.  You need to lose some portability and rely on something 
like POSIX or the Windows API or whatever.  But that doesn't make 
fopen() absurd or impossible to use -- a lot of code has been written 
that happily uses fopen() without worrying about any of the fancy 
OS-specific stuff.

[toc] | [prev] | [next] | [standalone]

#7871

On Jul 7, 11:42 am, Wojtek Lerch <wojte...@yahoo.ca> wrote:
> On 07/07/2011 12:40 PM, Malcolm McLean wrote:
>
> > On Jul 7, 7:31 pm, Wojtek Lerch<wojte...@yahoo.ca>  wrote:
>
> >> Do you find fopen() absurd and impossible to use too?  Or are file or
> >> stream attributes (such as the POSIX permission bits, or O_EXCL) less
> >> important to you than some of the thread attributes that POSIX or
> >> Windows have?
>
> > If it's the only interface to the file system, you may have problems.
>
> Or not, depending on what you're trying to do.
>
> > For instance you can't tell the size of a file, you can't scan a
> > directory, you can't set read or write permissions or flag it as a
> > temporary. You can't lock it from other processes.
>
> Right; but if you do need to do any of those things, then you can't rely
> on C99 alone.  You need to lose some portability and rely on something
> like POSIX or the Windows API or whatever.  But that doesn't make
> fopen() absurd or impossible to use -- a lot of code has been written
> that happily uses fopen() without worrying about any of the fancy
> OS-specific stuff.

I was under the impression that having something like fopen() (also)
work as an interface to a file system would make the function non-
portable.


Chad

[toc] | [prev] | [next] | [standalone]

#7873

On 2011-07-07, Chad <cdalten@gmail.com> wrote:
>
> I was under the impression that having something like fopen() (also)
> work as an interface to a file system would make the function non-
> portable.

The stream I/O functions cover the basic opening, reading, writing and
closing of files that nearly all file systems support. For many
purposes, this is enough. After all, reading and writing is the main
purpose of most files, yes?

It doesn't matter what is under the file. If the OS maps certain
functions to special files (like most Unix variants do for devices and
directories), it is potentially possible to interface with such things
by using the stream I/O functions. That doesn't make the stream I/O
functions themselves unportable.


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#7875

On Jul 7, 12:27 pm, Angel <angel+n...@spamcop.net> wrote:
> On 2011-07-07, Chad <cdal...@gmail.com> wrote:
>
>
>
> > I was under the impression that having something like fopen() (also)
> > work as an interface to a file system would make the function non-
> > portable.
>
> The stream I/O functions cover the basic opening, reading, writing and
> closing of files that nearly all file systems support. For many
> purposes, this is enough. After all, reading and writing is the main
> purpose of most files, yes?
>
> It doesn't matter what is under the file. If the OS maps certain
> functions to special files (like most Unix variants do for devices and
> directories), it is potentially possible to interface with such things
> by using the stream I/O functions. That doesn't make the stream I/O
> functions themselves unportable.
>

For some reason that doesn't sound right. Maybe I'm wrong. Nothing
personal, but I'm going to wait for either Mr. Keith Thompson or Dr.
Eric Sosman give their input on this whole thing.

[toc] | [prev] | [next] | [standalone]

#7879

On 2011-07-07, Chad <cdalten@gmail.com> wrote:
> On Jul 7, 12:27?pm, Angel <angel+n...@spamcop.net> wrote:
>> On 2011-07-07, Chad <cdal...@gmail.com> wrote:
>>
>>
>>
>> > I was under the impression that having something like fopen() (also)
>> > work as an interface to a file system would make the function non-
>> > portable.
>>
>> The stream I/O functions cover the basic opening, reading, writing and
>> closing of files that nearly all file systems support. For many
>> purposes, this is enough. After all, reading and writing is the main
>> purpose of most files, yes?
>>
>> It doesn't matter what is under the file. If the OS maps certain
>> functions to special files (like most Unix variants do for devices and
>> directories), it is potentially possible to interface with such things
>> by using the stream I/O functions. That doesn't make the stream I/O
>> functions themselves unportable.
>>
>
> For some reason that doesn't sound right. Maybe I'm wrong. Nothing
> personal, but I'm going to wait for either Mr. Keith Thompson or Dr.
> Eric Sosman give their input on this whole thing.

Maybe I just don't understand your question or concerns, but what in
this program that writes data from stdin to the Unix null device is so
wrong that it makes fopen() non-portable?

It does just what stream I/O is supposed to do: open a file, write stuff
to it, and close it. That the file happens to be mapped to a device
doesn't change anything one bit, does it?


#include <stdio.h>
#include <stdlib.h>

int main(void)
{
	FILE *devnull = fopen("/dev/null", "w");
	if (!devnull)
		return EXIT_FAILURE;
	
	int data;
	while ((data = fgetc(stdin)) != EOF)
		fputc(data, devnull);
	
	fclose(devnull);
	return EXIT_SUCCESS;
}


(Yes, I know, I don't test the return results of fputc() and fclose().
Since the (rather silly) purpose of this program is to discard data, I
didn't think it was important.)


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#7889

On 07/ 8/11 04:31 AM, Wojtek Lerch wrote:
> On 07/07/2011 6:33 AM, jacob navia wrote:
> ....
>> 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.
>
> Do you find fopen() absurd and impossible to use too?  Or are file or
> stream attributes (such as the POSIX permission bits, or O_EXCL) less
> important to you than some of the thread attributes that POSIX or
> Windows have?

Is really an appropriate analogy?  Using fopen or open is an 
implementation detail whereas the choice of thread implementation is a 
pretty fundamental design decision.

I agree there are similarities.  Both filesystem I/O and threading do 
require some degree of awareness of the operating environment, but I'd 
argue that dependency is stronger with threading.

 From a pthreads user's perspective the proposed API is close enough to 
pthreads with default options it be usable.  Provided implementations 
provide a means of mixing native and C1x thread, there shouldn't be many 
barriers to their adoption.  For example, on Solaris older native 
threads are compatible with pthreads, so the two can be mixed in the 
same application.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#7932

On 07/07/2011 5:14 PM, Ian Collins wrote:
> On 07/ 8/11 04:31 AM, Wojtek Lerch wrote:
>> On 07/07/2011 6:33 AM, jacob navia wrote:
>> ....
>>> 2) The proposed functions are absurd.
>>> ... so it is impossible to use.
>>
>> Do you find fopen() absurd and impossible to use too? Or are file or
>> stream attributes (such as the POSIX permission bits, or O_EXCL) less
>> important to you than some of the thread attributes that POSIX or
>> Windows have?
>
> Is really an appropriate analogy? Using fopen or open is an
> implementation detail whereas the choice of thread implementation is a
> pretty fundamental design decision.

Really?  I have written a lot of code using vanilla pthread_create() etc 
without setting any attributes to override any defaults of my threads, 
mutexes, or condvars; converting that code to the new C API would be 
purely a matter of mechanically renaming things.  On some other 
occassions, I did use some of the POSIX features that are absent int the 
C1X draft, and probably in many of those cases converting my code to C1X 
would require some non-trivial redesigning.  But I can say all the above 
about the C99 and POSIX file APIs -- choosing an API that supports 
directories, allows accessing unlinked files, and lets you control 
permissions can for sure impace the design compared to having to 
restrict your code to using the simplistic C99 file API.

> I agree there are similarities. Both filesystem I/O and threading do
> require some degree of awareness of the operating environment, but I'd
> argue that dependency is stronger with threading.

Could it be that the source of that feeling is the fact that the C1X 
threading API is new and unfamiliar?  If it had been around for a while, 
we would be used to the distinction between the basics covered by the C 
standard and the fancy stuff that requires you to give up some 
portability, just like we are in the file I/O area.  But for now, all 
the bits and pieces of the pthreads API feel equally "standard", and the 
ones absent from C1X feel "missing" as opposed to "less portable".

>  From a pthreads user's perspective the proposed API is close enough to
> pthreads with default options it be usable. Provided implementations
> provide a means of mixing native and C1x thread, there shouldn't be many
> barriers to their adoption. For example, on Solaris older native threads
> are compatible with pthreads, so the two can be mixed in the same
> application.

Yeah, I'm sure POSIX will define a mapping, just like today it does for 
mixing the C99 FILE API with the underlying file descriptor-based POSIX API.

[toc] | [prev] | [next] | [standalone]

#7934

On 07/ 8/11 03:58 PM, Wojtek Lerch wrote:
> On 07/07/2011 5:14 PM, Ian Collins wrote:
>> On 07/ 8/11 04:31 AM, Wojtek Lerch wrote:
>>> On 07/07/2011 6:33 AM, jacob navia wrote:
>>> ....
>>>> 2) The proposed functions are absurd.
>>>> ... so it is impossible to use.
>>>
>>> Do you find fopen() absurd and impossible to use too? Or are file or
>>> stream attributes (such as the POSIX permission bits, or O_EXCL) less
>>> important to you than some of the thread attributes that POSIX or
>>> Windows have?
>>
>> Is really an appropriate analogy? Using fopen or open is an
>> implementation detail whereas the choice of thread implementation is a
>> pretty fundamental design decision.
>
> Really?  I have written a lot of code using vanilla pthread_create() etc
> without setting any attributes to override any defaults of my threads,
> mutexes, or condvars; converting that code to the new C API would be
> purely a matter of mechanically renaming things.  On some other
> occassions, I did use some of the POSIX features that are absent int the
> C1X draft, and probably in many of those cases converting my code to C1X
> would require some non-trivial redesigning.  But I can say all the above
> about the C99 and POSIX file APIs -- choosing an API that supports
> directories, allows accessing unlinked files, and lets you control
> permissions can for sure impace the design compared to having to
> restrict your code to using the simplistic C99 file API.

Yes I agree with the above as I wrote later in my post.  In most cases 
the new API will save passing a NULL for the default action!  The 
pthreads feature I'll miss most is process shared, which is why I said 
it is important for standard and native threads to be compatible under 
the hood.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web