Path: csiph.com!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!de-l.enfer-du-nord.net!feeder2.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Markus Elfring <Markus.Elfring@web.de>
Newsgroups: comp.lang.c,comp.programming.threads
Subject: Re: Trivial C11 threads.h wrapper (public domain)
Date: Fri, 28 Sep 2012 12:05:37 +0200
Lines: 38
Message-ID: <50657671.1030606@web.de>
References: <slrnk67ihu.3ts.nuclear@goat.mutantstargoat.com> <50643C6A.6020609@web.de> <slrnk68us3.9lj.nuclear@goat.mutantstargoat.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
X-Trace: individual.net HdrmtRvwt0Efnawn5TtS2AUATeBfltm4aQC8FymRNUIk1AMqzVGE3oPB6pHzsH8d1C
Cancel-Lock: sha1:ZKZbDA1VKXtEIxb2/JPD/0M916M=
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120825 Thunderbird/15.0
In-Reply-To: <slrnk68us3.9lj.nuclear@goat.mutantstargoat.com>
Xref: csiph.com comp.lang.c:26736 comp.programming.threads:1104

> ... probably not, but it's not a matter of preference.
> Unless I'm much mistaken, the C11 standard dictates int as the type of
> the second argument of mtx_init (where all the mtx_ enumerations go),
> and as the return of all functions that need to indicate success
> or failure (thrd_ enumerations).

I suggest generally that a name is assigned to an enumeration. It might also be
a nice service if a "typedef" will be provided for each enumeration so that it
can become easier to reuse them as a data type in customised data structures.


> I just went through both docs and tried to map pthread error codes to
> corresponding C11-mandated error codes. Those that had no counterpart,
> I just ignored, or bundled them all together under thrd_error as
> appropriate. Do you propose a different strategy?

I guess that this implementation detail shows a software design challenge. I do
not like the ignorance of return values.


> Yes that was the most hairy bit. This mechanism doesn't seem to map
> exactly to what C11 wants. For instance the C standard talks about the
> possibility of having a mtx_timed | mtx_recursive mutex, but as far as
> I can tell with pthreads I can specify either PTHREAD_MUTEX_RECURSIVE or
> PTHREAD_MUTEX_TIMED_NP (which is not even standard), but not both.

Thanks that you pointed out such a portability issue.

I would like to point out once again that your function call
"pthread_mutexattr_init" shows the case of an unused return value. I would
prefer complete error detection and corresponding exception handling.

Some functions from the C standard API (like "mtx_destroy") have got the return
type "void". But the called Pthreads function provides an error code eventually.
How do you think about the reaction "abort()" in this use case?

Regards,
Markus