Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Ian Collins Newsgroups: comp.std.c,comp.lang.c Subject: Re: The threading specs in the standard: a new catastrophe Date: Fri, 08 Jul 2011 09:14:20 +1200 Lines: 41 Message-ID: <97mluqFbcvU6@mid.individual.net> References: <97m59uF1nsU1@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 oBj1Hl2PwJtccVNPM9WGSw7jBOaxDAGKCkJI/J2o0QsqUcZDFg Cancel-Lock: sha1:pLdJutdoTyyv0DQbQCVfkGRaqSA= User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.2.9) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.4 In-Reply-To: <97m59uF1nsU1@mid.individual.net> Xref: x330-a1.tempe.blueboxinc.net comp.std.c:622 comp.lang.c: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