Still no dirent.h in C1X

[Lauri Alanko]

That is fucking stupid, but it's what you expect from a committee working on
the N-th revision of a programming language.

Maybe you should read Boehm's "Threads cannot be implemented as a
Library" for some rationale:

http://www.hpl.hp.com/techreports/2004/HPL-2004-209.html

The point of thread support in C1X is not the API for spawning threads
and synchronization primitives: that's evidently lifted quite
straightforwardly from pthreads. The point is 5.1.2.4 in N1570.


Lauri

 

[jacob navia]

Le 26/11/11 20:23, Stephen Sprunk a écrit :

The "data" there is completely useless.

OK, OK. That is surely enough. You say that data is "useless"
and that was it. No firther arguments, nothing.


OK, another one is the respected tiobe index

http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html

C appears in the second position.

For many embedded systems, the _only_ language available is C, and there
is no OS to speak of. Many don't have file systems at all, and of those
that have file systems, some don't have a concept of directories because
they only need to manage a small (and fixed) set of files.

Obviously directories can ONLY happen to exist in a file system...
For all systems without them it would be very easy to have ONE
huge directory that contains everything if they have the concept of
files at all!

Embedded systems outnumber hosted systems by at least an order of magnitude.

So what?

Should we eliminate file i/o because there are a lot of embedded systems
without any files?

Or should we eliminate math.h?

What is the use of having a time.h if the toaster has no clock?

I do not understand the philosophy:

"*I* do not need it therefore feature XXX is useless, just 'cruft'."

And if there are 1 million toasters around who cares?

There is surely 1 dvelopment system and ONE developer for all those!

 

[André Gillibert]

You may not be aware that many, probably the majority, of C programs run
on systems without any notion of directories.

And on many embedded systems where no full OS is started, no file
system is implemented and fopen don't make sense either.

For example, embedded
processors, but also many mainframe systems. It's only a few months ago
that I was doing some maintenance work on a UNISYS A Series, which has a
flat file system. This is not unusual for mainframes in current use.

In that case, opendir()/readdir()/closedir() might still be
implemented on a flat root directory, and mkdir(2) would always fail,
unless listing is not possible.

C should not be ladened with cruft that simply doesn't make sense on a
large proportion of implementations.

It also makes sense on a large proportion of implementations. Having a
standard way to support directories is useful on these implementations.
Fortunately, as Kaz Kylheku told, we already have POSIX and there is
no need to merge C and POSIX.

 

[lawrence.jones]

It is.

No, it is not. It is similar to pthreads, but that's just because it
provides many of the same capabilities. It's also similar to Windows
threads for the same reason. It's intended to be a generic interface
that can be easily implemented on top of any existing thread support
(but particularly POSIX threads and Windows threads).

 

[James Kuyper]

It is. Basically, if you prefix every function with "pthread_" and spell
out the second part completely ("cnd" -> "cond", "mtx"->"mutex", etc.)
you get the complete POSIX threads library.

Which is funny, because that itself is a library on Linux, wrapping
around system calls. So, up until now the C library wrapped system
calls, and now the C libary wraps the thread library, which wraps the
system calls. Nice job!

For 2/3 of the functions in <threads.h>, I was able to match them up
that way with <pthread.h> functions, with the following exceptions:

From n1570.pdf "Committee Draft — April 12, 2011 ISO/IEC 9899:201x",
section B.25:

Theads <threads.h>:
...
int mtx_timedlock(mtx_t *restrict mtx,
const struct timespec *restrict ts); ....
thrd_t thrd_current(void); ....
int thrd_sleep(const struct timespec *duration,
struct timespec *remaining); ....
void thrd_yield(void);
int tss_create(tss_t *key, tss_dtor_t dtor);
void tss_delete(tss_t key);
void *tss_get(tss_t key);
int tss_set(tss_t key, void *val);

Could you please identify which <pthread.h> functions correspond to the
above <threads.h> functions?

When I went to http://www3.opengroup.org/unix/, I got the following notice:

Please note that on Sunday November 27 our servers are undergoing planned maintenance between 00:30 and 10:00 PST and some pages will be temporarily unavailable during that time.

I'm a little two impatient to wait that long. Therefore, for now, I'm
relying upon the contents of pthreads.h on my desktop, which is an
Ubuntu Linux machine. I'm not sure how accurately it conforms to POSIX.
It contains a lot of gcc-specific stuff, which I've removed where I
recognized it. Here's the list of functions prefixed with "pthread_"
that I extracted from that source, excluding those which clearly matched

extern pthread_t pthread_self (void) __attribute__ ((const__));
extern int pthread_attr_init (pthread_attr_t *__attr) ;
extern int pthread_attr_destroy (pthread_attr_t *__attr);
extern int pthread_attr_getdetachstate (const pthread_attr_t *__attr,
int *__detachstate);
extern int pthread_attr_setdetachstate (pthread_attr_t *__attr,
int __detachstate);
extern int pthread_attr_getguardsize (const pthread_attr_t *__attr,
size_t *__guardsize);
extern int pthread_attr_setguardsize (pthread_attr_t *__attr,
size_t __guardsize);
extern int pthread_attr_getschedparam (const pthread_attr_t *restrict
__attr,
struct sched_param *restrict __param);
extern int pthread_attr_setschedparam (pthread_attr_t *restrict __attr,
const struct sched_param *restrict
__param);
extern int pthread_attr_getschedpolicy (const pthread_attr_t *restrict
__attr, int *restrict __policy)
extern int pthread_attr_setschedpolicy (pthread_attr_t *__attr, int __policy);
extern int pthread_attr_getinheritsched (const pthread_attr_t *restrict
__attr, int *restrict __inherit);
extern int pthread_attr_setinheritsched (pthread_attr_t *__attr,
int __inherit);
extern int pthread_attr_getscope (const pthread_attr_t *restrict __attr, int *restrict __scope);
extern int pthread_attr_setscope (pthread_attr_t *__attr, int __scope);
extern int pthread_attr_getstackaddr (const pthread_attr_t *restrict
__attr, void **restrict __stackaddr);
extern int pthread_attr_setstackaddr (pthread_attr_t *__attr,
void *__stackaddr);
extern int pthread_attr_getstacksize (const pthread_attr_t *restrict
__attr, size_t *restrict __stacksize);
extern int pthread_attr_setstacksize (pthread_attr_t *__attr,
size_t __stacksize);
extern int pthread_setschedparam (pthread_t __target_thread, int __policy, const struct sched_param *__param);
extern int pthread_getschedparam (pthread_t __target_thread,
int *restrict __policy,
struct sched_param *restrict __param);
extern int pthread_setschedprio (pthread_t __target_thread, int __prio);
extern int pthread_setcancelstate (int __state, int *__oldstate);
extern int pthread_setcanceltype (int __type, int *__oldtype);
extern int pthread_cancel (pthread_t __th);
extern void pthread_testcancel (void);
extern int pthread_mutex_getprioceiling (const pthread_mutex_t *
restrict __mutex,
int *restrict __prioceiling);
extern int pthread_mutex_setprioceiling (pthread_mutex_t *restrict __mutex,
int __prioceiling,
int *restrict __old_ceiling);
extern int pthread_mutexattr_init (pthread_mutexattr_t *__attr);
extern int pthread_mutexattr_destroy (pthread_mutexattr_t *__attr);
extern int pthread_mutexattr_getpshared (const pthread_mutexattr_t *
restrict __attr,
int *restrict __pshared);
extern int pthread_mutexattr_setpshared (pthread_mutexattr_t *__attr,
int __pshared);
extern int pthread_mutexattr_getprotocol (const pthread_mutexattr_t *
restrict __attr,
int *restrict __protocol));
extern int pthread_mutexattr_setprotocol (pthread_mutexattr_t *__attr,
int __protocol);
extern int pthread_mutexattr_getprioceiling (const pthread_mutexattr_t *
restrict __attr,
int *restrict __prioceiling);
extern int pthread_mutexattr_setprioceiling (pthread_mutexattr_t *__attr,
int __prioceiling);
extern int pthread_condattr_init (pthread_condattr_t *__attr);
extern int pthread_condattr_destroy (pthread_condattr_t *__attr);
extern int pthread_condattr_getpshared (const pthread_condattr_t *
restrict __attr,
int *restrict __pshared);
extern int pthread_condattr_setpshared (pthread_condattr_t *__attr,
int __pshared) ;
extern int pthread_key_create (pthread_key_t *__key,
void (*__destr_function) (void *));
extern int pthread_key_delete (pthread_key_t __key);

extern void *pthread_getspecific (pthread_key_t __key);
extern int pthread_setspecific (pthread_key_t __key,
const void *__pointer) ;
extern int pthread_atfork (void (*__prepare) (void),
void (*__parent) (void),
void (*__child) (void));

Could you please identify the <threads.h> analogs of those functions?

By my count (and I'll freely admit the possibility of a miscount), there
are 24 functions defined in <threads.h>. I could find no <pthread.h>
analog for 8 of them. I found 61 functions with names starting with
pthread_ in the <pthread.h> on my machine. I could find no <threads.h>
analog for 45 of them. I don't know how many of those might be
extensions to the POSIX standard library. However, your claim that,
simply by modifying the names of the <threads.h> functions, "you get the
complete POSIX threads library." seems very substantially exaggerated.
It doesn't look at all complete to me.

 

[Kaz Kylheku]

For 2/3 of the functions in <threads.h>, I was able to match them up
that way with <pthread.h> functions, with the following exceptions:

From n1570.pdf "Committee Draft — April 12, 2011 ISO/IEC 9899:201x",
section B.25:
...

Hi James,

pthread_mutex_timedlock

http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_timedlock.html

pthread_self

nanosleep

sched_yield

http://pubs.opengroup.org/onlinepubs/009695399/functions/sched_yield.html

pthread_key_create, pthread_getspecific, etc.

Could you please identify which <pthread.h> functions correspond to the
above <threads.h> functions?

As requested.

 

[James Kuyper]

On 11/27/2011 11:52 AM, Kaz Kylheku wrote:
....

As requested.

Any comments on the three dozen other pthread_* functions I listed for
which I could not identify any <thread.h> equivalent? The claim that
<threads.h> corresponds to the complete POSIX threads library was made
by Markus, not you, but he hasn't responded yet, and you have.

 

[Kaz Kylheku]

On 11/27/2011 11:52 AM, Kaz Kylheku wrote:
...

Any comments on the three dozen other pthread_* functions I listed for
which I could not identify any <thread.h> equivalent?

That's going to be the case because this thread.h is just some toy invention
whereas pthreads is a years-old mature thing that was bred out of real
implementations.

A better way to design a portable threading interface for C would be to take
the subset of POSIX which is matched by <thread.h>, and just refer to the
original document along with the subset.

This way, certain programs with POSIX threads could become ISO C programs
without having to be rewritten.

There are already portable implementations of POSIX threads. If you want POSIX
threads on Win32, you can get it.

Nobody needs new spellings for the same thing.

 

[lawrence.jones]

There are already portable implementations of POSIX threads. If you want POSIX
threads on Win32, you can get it.

People keep saying that, but no one has yet provided a reference to an
implementation that is usable by normal Windows (Win32) programs. All
the known examples require some sort of POSIX environment (which is
quite reasonable since pthreads are intimately tied to POSIX; C threads
are not).

 

[Markus Wichmann]

Could you please identify the <threads.h> analogs of those functions?

By my count (and I'll freely admit the possibility of a miscount), there
are 24 functions defined in <threads.h>. I could find no <pthread.h>
analog for 8 of them. I found 61 functions with names starting with
pthread_ in the <pthread.h> on my machine. I could find no <threads.h>
analog for 45 of them. I don't know how many of those might be
extensions to the POSIX standard library. However, your claim that,
simply by modifying the names of the <threads.h> functions, "you get the
complete POSIX threads library." seems very substantially exaggerated.
It doesn't look at all complete to me.

There you go! I display my inability to correctly write down my thoughts
and, poof, there is a pedant pointing that out to me. I'm sorry if I
gave you mistaken hope.

<threads.h> is part of the (future) C library, which is kept thin
deliberately. There is of course no way it could ever amount to the same
feature set of pthreads. What I meant to say was that you can really map
each function in <threads.h> to a pthread or other POSIX function. And
that is one-to-one, just so we are on the same page. For instance, file
I/O is not directly mappable one-to-one between standard C and POSIX
(that is, the part of POSIX that is not standard C. The implementation
of those functions amounts to more than just wrapping another function).

In short: You can map any function name in <threads.h> exactly to one of
the functions in <pthread.h> or <sched.h> or <unistd.h> or... That is
not possible the other way round.

I hope that was clear enough.

CYA,
Markus

 

[James Kuyper]

On 11/27/2011 01:48 PM, Kaz Kylheku wrote:
....

There are already portable implementations of POSIX threads. If you want POSIX
threads on Win32, you can get it.

I'm no expert on Windows programming, I just listened to the debate in
the "C is fixed?" and "The threading specs in the new standard: a new
catastrophe" threads during July and August this year. Many people
participating in those threads knew a lot more about it than I do. Some
experts claimed that POSIX threads only worked in the POSIX subsystem of
Win32, and that most features of Window are NOT available when using
that subsystem. Those people provided links to Microsoft documentation
that appeared to support that claim. Those who's response to the claim
was to say "what POSIX subsystem? I've no idea what you're talking
about" never bothered to address the issues raised by the links that the
first group provided. I found the first group's claims correspondingly
more believable.

The <threads.h> interface was intended to be designed so it could, among
other things, be implemented as a thin wrapper over native threading
features of Windows, as well as other non-POSIX systems. It should
therefore be usable in native Windows mode programs, and not just
programs written for the POSIX subsystem of Win32. I've no idea whether
they achieved that goal.

I never received an answer from anyone to either of my questions to Rui
Maciel on 2011-07-12 in the "C is fixed?" thread. Would you care to
answer them?

 

[John Tsiombikas]

People keep saying that, but no one has yet provided a reference to an
implementation that is usable by normal Windows (Win32) programs. All
the known examples require some sort of POSIX environment (which is
quite reasonable since pthreads are intimately tied to POSIX; C threads
are not).

Not that it has much relevance in this newsgroup, but I've used this
one: http://sourceware.org/pthreads-win32/ in the past, it works
perfectly as far as I can tell, and I don't have any recollection of it
needing any posix wrappers of any sort (I imagine you refer to something
like cygwin).

I've even written my own pthreads wrapper for win32 threads at one
point. I cannot claim the same level of completeness or correctness as
the implementation I just mentioned, but I definitely didn't need
anything from POSIX to do it, just calls to win32 threading functions.
In fact most of the pthread functions mapped 1-1 to win32 functions
except for condvars which required a more invovled implementation as far
as I remember.

So I can't really see what's so intimately tied to POSIX as you
asserted.

 

[James Kuyper]

On 11/27/2011 05:30 PM, Markus Wichmann wrote:
....

There you go! I display my inability to correctly write down my thoughts
and, poof, there is a pedant pointing that out to me. I'm sorry if I
gave you mistaken hope.

I'm sorry, but the distinction between implementing 1/3 of POSIX threads
and "the complete POSIX threads library" doesn't seem like mere pedantry
to me. It represents extremely sloppy writing to conflate the two, and
suggests comparably sloppy thinking.

Don't worry about depriving me of hope - I already knew that <threads.h>
overlaps only part of <pthreads.h>; I was just calling you on your claim
to contrary.

 

[Markus Wichmann]

On 11/27/2011 05:30 PM, Markus Wichmann wrote:
...

I'm sorry, but the distinction between implementing 1/3 of POSIX threads
and "the complete POSIX threads library" doesn't seem like mere pedantry
to me. It represents extremely sloppy writing to conflate the two, and
suggests comparably sloppy thinking.

Have a look at the time header above the message in question. My
thinking didn't get much more sloppy that day.

CYA,
Markus

 

[Joshua Maurice]

That's going to be the case because this thread.h is just some toy invention
whereas pthreads is a years-old mature thing that was bred out of real
implementations.

A better way to design a portable threading interface for C would be to take
the subset of POSIX which is matched by <thread.h>, and just refer to the
original document along with the subset.

This way, certain programs with POSIX threads could become ISO C programs
without having to be rewritten.

There are already portable implementations of POSIX threads. If you want POSIX
threads on Win32, you can get it.

Nobody needs new spellings for the same thing.

I suspect there were three reasons this was done.

First, political. If you call it pthreads, I suspect Microsoft will
have some additional bias against implementing it. That is bad.

Second, the POSIX spec is woefully underspecified and ambiguous, and
flat out wrong (the try_lock problem), in some areas. The cleanup is
welcome.

Third, it's not well defined what it would mean to implement only part
of POSIX. POSIX depends on the C standard, and we don't want to
introduce a cyclical dependencies of standards if we can help it.

Also, as noted else-thread, we're getting portable memory barriers,
portable atomic exchanges, and such. Thank goodness. Finally.

 

[Markus Wichmann]

I suspect there were three reasons this was done.

First, political. If you call it pthreads, I suspect Microsoft will
have some additional bias against implementing it. That is bad.

There's no need for M$ to implement pthreads, as there's already a
wrapper library for Win32, wrapping pthreads around Win32 threads. It's
called pthreads-win32.

Second, the POSIX spec is woefully underspecified and ambiguous, and
flat out wrong (the try_lock problem), in some areas. The cleanup is
welcome.

Could you elaborate or give pointers? Google didn't turn up anything
useful for the try_lock problem. Do you mean, that an application that
received a false on return of try_lock() doesn't know whether that was
just a temporary failure (aka Race Condition) or that an application
that constantly calls try_lock() won't be enqueued to the mutex the same
as an application that calls lock() is, leading to a situation where
constantly calling try_lock() results in an endless wait while lock()
would have succeeded by now?

Third, it's not well defined what it would mean to implement only part
of POSIX. POSIX depends on the C standard, and we don't want to
introduce a cyclical dependencies of standards if we can help it.

Yeah, that's why we should propably copy that part of POSIX into C
instead of simply adding pointers.

Also, as noted else-thread, we're getting portable memory barriers,
portable atomic exchanges, and such. Thank goodness. Finally.

Yeah, that's definitely a plus. I was getting tired of rewriting the
same algorithms for each CPU someone wanted added.

CYA,
Markus

 

[James Kuyper]

On 28.11.2011 22:51, Joshua Maurice wrote: ....
There's no need for M$ to implement pthreads, as there's already a
wrapper library for Win32, wrapping pthreads around Win32 threads. It's
called pthreads-win32.

Which only implements a subset of POSIX pthreads. See

Yeah, that's why we should propably copy that part of POSIX into C
instead of simply adding pointers.

Wrapping it has some advantages over copying it. That way, if POSIX
changes the specification for a component of pthreads, an implementation
can continue to be conforming to both the C and POSIX standards by
working around the change inside the wrapper.

 

[Kaz Kylheku]

Wrapping it has some advantages over copying it. That way, if POSIX
changes the specification for a component of pthreads, an implementation
can continue to be conforming to both the C and POSIX standards by
working around the change inside the wrapper.

POSIX has feature selection macros for different versions of the
interface.

 

[Joshua Maurice]

There's no need for M$ to implement pthreads, as there's already a
wrapper library for Win32, wrapping pthreads around Win32 threads. It's
called pthreads-win32.

If we want to add pthreads, or a direct copy-paste of pthreads spec to
the C spec, then Microsoft has to implement it, or we bifurcate the
language, and I think we can all agree that would be bad, or at best
neutral to what we have now. (I argue worse because then they might
start ignoring other aspects of the C standard. Gives them precedent,
now that they can never be fully conforming.) I suspect there would be
political pushback from Microsoft because of the names. If we can
avoid that political mess by simply adopting new names, I'm all for
that.

Could you elaborate or give pointers? Google didn't turn up anything
useful for the try_lock problem. Do you mean, that an application that
received a false on return of try_lock() doesn't know whether that was
just a temporary failure (aka Race Condition) or that an application
that constantly calls try_lock() won't be enqueued to the mutex the same
as an application that calls lock() is, leading to a situation where
constantly calling try_lock() results in an endless wait while lock()
would have succeeded by now?

Reordering Constraints for Pthread-Style Locks (2005)
by Hans-j. Boehm
http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.85.9908

The paper talks about a lot of things, including this issue. The
really short version is: Because the simple reading of
int pthread_mutex_trylock(pthread_mutex_t *mutex);
http://pubs.opengroup.org/onlinepubs/007904875/functions/pthread_mutex_lock.html
guarantees that pthread_mutex_trylock will acquire the mutex iff no
other thread currently has it, and thus pthread_mutex_trylock will
fail to acquire iff another thread currently has it, and the simple
rules of how threading without race conditions is basically
"expression" interleavings, then we can write some "interesting" code
that that assumes certain memory operations are visible in this thread
when trylock returns failure. However, as pthreads is commonly
implemented, this is very not true.

C++11 and C1x fix this by allowing trylock to fail spuriously (and
properly documenting the acquire and release semantics of
acquire_mutex and release_mutex). When trylock returns failure in C+
+11 / C1x, this gives you no useful information; another thread may
have the mutex, and it's possible currently no thread has the mutex.
In practice, it won't be implemented to randomly fail, but the formal
specification of allowing spurious failures (along with properly
documenting acquire and release semantics) remove these troublesome
executions which abuse trylock.

 

[Ian Collins]

If we want to add pthreads, or a direct copy-paste of pthreads spec to
the C spec, then Microsoft has to implement it, or we bifurcate the
language, and I think we can all agree that would be bad, or at best
neutral to what we have now. (I argue worse because then they might
start ignoring other aspects of the C standard. Gives them precedent,
now that they can never be fully conforming.) I suspect there would be
political pushback from Microsoft because of the names. If we can
avoid that political mess by simply adopting new names, I'm all for
that.

Haven't they already ignored C99?