Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Wojtek Lerch Newsgroups: comp.std.c,comp.lang.c Subject: Re: The threading specs in the standard: a new catastrophe Date: Thu, 07 Jul 2011 23:58:06 -0400 Lines: 49 Message-ID: <97ndh8F5p5U1@mid.individual.net> References: <97m59uF1nsU1@mid.individual.net> <97mluqFbcvU6@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net 1StviEKTHfxOzS+CzB6I7gz27H4WkWPGg32+IDyC0tx2PSv6QF Cancel-Lock: sha1:4/+yLnkFFVMg6XmpESrthbINkSM= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11 In-Reply-To: <97mluqFbcvU6@mid.individual.net> Xref: x330-a1.tempe.blueboxinc.net comp.std.c:637 comp.lang.c: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.