From owner-freebsd-threads@FreeBSD.ORG Mon Mar 8 05:55:33 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A21816A4CE for ; Mon, 8 Mar 2004 05:55:33 -0800 (PST) Received: from web12405.mail.yahoo.com (web12405.mail.yahoo.com [216.136.173.132]) by mx1.FreeBSD.org (Postfix) with SMTP id 719DB43D45 for ; Mon, 8 Mar 2004 05:55:33 -0800 (PST) (envelope-from toposoph-space@yahoo.com) Message-ID: <20040308135533.28705.qmail@web12405.mail.yahoo.com> Received: from [12.34.23.5] by web12405.mail.yahoo.com via HTTP; Mon, 08 Mar 2004 05:55:33 PST Date: Mon, 8 Mar 2004 05:55:33 -0800 (PST) From: To: freebsd-threads@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: %fs, %gs and ldt X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2004 13:55:33 -0000 Hi, Is there any version of ABI which specifies %fs, %gs and ldt usage on ia32 for *nix? Or any FreeBSD specification? I see that Nvidia driver uses them, that there is some compatibility with Linux, that FreeBSD kernel did not save %gs on context switch recently and not does %gs processing, etc., etc. But I can not find what is the general idea of using those things or what is intend for future usage. Thank you in advance for any info, Sergey. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 8 05:59:32 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7233B16A4CE for ; Mon, 8 Mar 2004 05:59:32 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F69F43D1D for ; Mon, 8 Mar 2004 05:59:32 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i28DxVEK006126; Mon, 8 Mar 2004 08:59:31 -0500 (EST) Date: Mon, 8 Mar 2004 08:59:31 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: toposoph-space@yahoo.com In-Reply-To: <20040308135533.28705.qmail@web12405.mail.yahoo.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: freebsd-threads@freebsd.org Subject: Re: %fs, %gs and ldt X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2004 13:59:32 -0000 On Mon, 8 Mar 2004 toposoph-space@yahoo.com wrote: > Hi, > > Is there any version of ABI which specifies %fs, %gs and ldt usage on > ia32 for *nix? Or any FreeBSD specification? I see that Nvidia driver > uses them, that there is some compatibility with Linux, that FreeBSD > kernel did not save %gs on context switch recently and not does %gs > processing, etc., etc. But I can not find what is the general idea of > using those things or what is intend for future usage. > Thank you in advance for any info, See http://people.redhat.com/~drepper/tls.pdf We're working towards adopting that by 5.3-release. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Mon Mar 8 11:01:45 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6113716A4CE for ; Mon, 8 Mar 2004 11:01:45 -0800 (PST) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4299843D1D for ; Mon, 8 Mar 2004 11:01:45 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) i28J1jbv072808 for ; Mon, 8 Mar 2004 11:01:45 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.10/8.12.10/Submit) id i28J1icZ072802 for freebsd-threads@freebsd.org; Mon, 8 Mar 2004 11:01:44 -0800 (PST) (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 8 Mar 2004 11:01:44 -0800 (PST) Message-Id: <200403081901.i28J1icZ072802@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2004 19:01:45 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/06/13] kern/19247 threads uthread_sigaction.c does not do anything 1 problem total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/07/18] kern/20016 threads pthreads: Cannot set scheduling timer/Can o [2000/08/26] misc/20861 threads libc_r does not honor socket timeouts o [2001/01/19] bin/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVT o [2001/01/25] bin/24632 threads libc_r delicate deviation from libc in ha o [2001/01/25] misc/24641 threads pthread_rwlock_rdlock can deadlock o [2001/11/26] bin/32295 threads pthread dont dequeue signals o [2002/02/01] i386/34536 threads accept() blocks other threads o [2002/05/25] kern/38549 threads the procces compiled whith pthread stoppe o [2002/06/27] bin/39922 threads [PATCH?] Threaded applications executed w o [2002/08/04] misc/41331 threads Pthread library open sets O_NONBLOCK flag o [2003/03/02] bin/48856 threads Setting SIGCHLD to SIG_IGN still leaves z o [2003/03/10] bin/49087 threads Signals lost in programs linked with libc a [2003/04/08] bin/50733 threads buildworld won't build, because of linkin o [2003/05/07] bin/51949 threads thread in accept cannot be cancelled 14 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/05/25] misc/18824 threads gethostbyname is not thread safe o [2000/10/21] misc/22190 threads A threaded read(2) from a socketpair(2) f o [2001/09/09] bin/30464 threads pthread mutex attributes -- pshared o [2002/05/02] bin/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwri s [2002/07/16] misc/40671 threads pthread_cancel doesn't remove thread from 5 problems total. From owner-freebsd-threads@FreeBSD.ORG Thu Mar 11 05:59:18 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 776FE16A4CE for ; Thu, 11 Mar 2004 05:59:18 -0800 (PST) Received: from mxfep01.bredband.com (mxfep01.bredband.com [195.54.107.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 30C7043D2D for ; Thu, 11 Mar 2004 05:59:17 -0800 (PST) (envelope-from torger@ludd.luth.se) Received: ([213.115.124.33] [213.115.124.33]) by mxfep01.bredband.com with ESMTP <20040311135911.PKA20089.mxfep01.bredband.com@c-217c73d5.022-251-6c756c10.cust.bredbandsbolaget.se> for ; Thu, 11 Mar 2004 14:59:11 +0100 From: Anders Torger To: freebsd-threads@freebsd.org Date: Thu, 11 Mar 2004 14:59:11 +0100 User-Agent: KMail/1.6.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200403111459.11287.torger@ludd.luth.se> Subject: Does PTHREAD_MUTEX_INITIALIZER work? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2004 13:59:18 -0000 Do the PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER macros really work? What puzzles me is that pthread.h says: #define PTHREAD_MUTEX_INITIALIZER NULL #define PTHREAD_COND_INITIALIZER NULL that is the initialisers are NULL. I get some strange random temporary lockups and deaths in my program when running it on FreeBSD (5.0), while it works flawlessy on Linux, and one reason could perhaps be that the initialisers do not work on FreeBSD. /Anders Torger From owner-freebsd-threads@FreeBSD.ORG Thu Mar 11 06:07:10 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5358216A4CE for ; Thu, 11 Mar 2004 06:07:10 -0800 (PST) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C4E243D39 for ; Thu, 11 Mar 2004 06:07:09 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h81.vuokselantie10.fi [193.64.42.129]) by rms04.rommon.net (8.12.9p1/8.12.9) with ESMTP id i2BE76cM084433; Thu, 11 Mar 2004 16:07:06 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <40507287.1040203@he.iki.fi> Date: Thu, 11 Mar 2004 16:07:03 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Torger References: <200403111459.11287.torger@ludd.luth.se> In-Reply-To: <200403111459.11287.torger@ludd.luth.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Does PTHREAD_MUTEX_INITIALIZER work? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2004 14:07:10 -0000 Anders Torger wrote: >Do the PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER macros >really work? > >What puzzles me is that pthread.h says: > >#define PTHREAD_MUTEX_INITIALIZER NULL >#define PTHREAD_COND_INITIALIZER NULL > >that is the initialisers are NULL. > >I get some strange random temporary lockups and deaths in my program >when running it on FreeBSD (5.0), while it works flawlessy on Linux, >and one reason could perhaps be that the initialisers do not work on >FreeBSD. > > > 5.0 is an early new technology release, I would suggest using 5.2.1 when reporting issues. Pete From owner-freebsd-threads@FreeBSD.ORG Thu Mar 11 07:16:18 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EE25F16A4CE for ; Thu, 11 Mar 2004 07:16:18 -0800 (PST) Received: from mxfep02.bredband.com (mxfep02.bredband.com [195.54.107.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id A981B43D2F for ; Thu, 11 Mar 2004 07:16:17 -0800 (PST) (envelope-from torger@ludd.luth.se) Received: ([213.115.124.33] [213.115.124.33]) by mxfep02.bredband.com with ESMTP <20040311151616.PYT13311.mxfep02.bredband.com@c-217c73d5.022-251-6c756c10.cust.bredbandsbolaget.se>; Thu, 11 Mar 2004 16:16:16 +0100 From: Anders Torger To: Petri Helenius Date: Thu, 11 Mar 2004 16:16:15 +0100 User-Agent: KMail/1.6.1 References: <200403111459.11287.torger@ludd.luth.se> <40507287.1040203@he.iki.fi> In-Reply-To: <40507287.1040203@he.iki.fi> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403111616.15668.torger@ludd.luth.se> cc: freebsd-threads@freebsd.org Subject: Re: Does PTHREAD_MUTEX_INITIALIZER work? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2004 15:16:19 -0000 On Thursday 11 March 2004 15.07, you wrote: > Anders Torger wrote: > >Do the PTHREAD_MUTEX_INITIALIZER and PTHREAD_COND_INITIALIZER macros > >really work? > > > >What puzzles me is that pthread.h says: > > > >#define PTHREAD_MUTEX_INITIALIZER NULL > >#define PTHREAD_COND_INITIALIZER NULL > > > >that is the initialisers are NULL. > > > >I get some strange random temporary lockups and deaths in my program > >when running it on FreeBSD (5.0), while it works flawlessy on Linux, > >and one reason could perhaps be that the initialisers do not work on > >FreeBSD. > > 5.0 is an early new technology release, I would suggest using 5.2.1 > when reporting issues. PTHREAD_MUTEX_INITIALIZER is defined as NULL in 5.2.1 too. I shall test the software on that platform later though. However, it would be nice if someone could explain this NULL thing (it is not NULL on other pthread implementations I have looked at). Perhaps there is a perfectly natural explanation? /Anders Torger From owner-freebsd-threads@FreeBSD.ORG Thu Mar 11 08:22:29 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5697616A4CE for ; Thu, 11 Mar 2004 08:22:29 -0800 (PST) Received: from rms04.rommon.net (rms04.rommon.net [212.54.2.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3230143D1D for ; Thu, 11 Mar 2004 08:22:28 -0800 (PST) (envelope-from pete@he.iki.fi) Received: from he.iki.fi (h81.vuokselantie10.fi [193.64.42.129]) by rms04.rommon.net (8.12.9p1/8.12.9) with ESMTP id i2BGMQcM084798; Thu, 11 Mar 2004 18:22:26 +0200 (EET) (envelope-from pete@he.iki.fi) Message-ID: <4050923F.5010307@he.iki.fi> Date: Thu, 11 Mar 2004 18:22:23 +0200 From: Petri Helenius User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Anders Torger References: <200403111459.11287.torger@ludd.luth.se> <40507287.1040203@he.iki.fi> <200403111616.15668.torger@ludd.luth.se> In-Reply-To: <200403111616.15668.torger@ludd.luth.se> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: Does PTHREAD_MUTEX_INITIALIZER work? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2004 16:22:29 -0000 Anders Torger wrote: > PTHREAD_MUTEX_INITIALIZER is defined as NULL in 5.2.1 too. I shall test > >the software on that platform later though. However, it would be nice >if someone could explain this NULL thing (it is not NULL on other >pthread implementations I have looked at). Perhaps there is a perfectly >natural explanation? > > > NULL is the only value you can safely set a pointer to which cannot be a valid value? Pete From owner-freebsd-threads@FreeBSD.ORG Thu Mar 11 11:28:59 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8FBF416A4CE for ; Thu, 11 Mar 2004 11:28:59 -0800 (PST) Received: from smtp.des.no (flood.des.no [217.116.83.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5079C43D45 for ; Thu, 11 Mar 2004 11:28:59 -0800 (PST) (envelope-from des@des.no) Received: by smtp.des.no (Pony Express, from userid 666) id 271735310; Thu, 11 Mar 2004 20:28:58 +0100 (CET) Received: from dwp.des.no (des.no [80.203.228.37]) by smtp.des.no (Pony Express) with ESMTP id 8A482530A; Thu, 11 Mar 2004 20:28:47 +0100 (CET) Received: by dwp.des.no (Postfix, from userid 2602) id 060A333CA6; Thu, 11 Mar 2004 20:28:46 +0100 (CET) To: Anders Torger References: <200403111459.11287.torger@ludd.luth.se> <40507287.1040203@he.iki.fi> <200403111616.15668.torger@ludd.luth.se> From: des@des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Thu, 11 Mar 2004 20:28:46 +0100 In-Reply-To: <200403111616.15668.torger@ludd.luth.se> (Anders Torger's message of "Thu, 11 Mar 2004 16:16:15 +0100") Message-ID: User-Agent: Gnus/5.090024 (Oort Gnus v0.24) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on flood.des.no X-Spam-Level: X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.63 cc: freebsd-threads@freebsd.org Subject: Re: Does PTHREAD_MUTEX_INITIALIZER work? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2004 19:28:59 -0000 Anders Torger writes: > PTHREAD_MUTEX_INITIALIZER is defined as NULL in 5.2.1 too. I shall > test the software on that platform later though. However, it would > be nice if someone could explain this NULL thing Our pthread_mutex_t is a pointer type, and the pthread_mutex_* functions will automatically create a new mutex with default attributes if the specified mutex is NULL (remember that it is passed by reference, so they can replace NULL with a pointer to the new mutex structure) > (it is not NULL on > other pthread implementations I have looked at). Other implementations may define pthread_mutex_t as a struct, in which case PTHREAD_MUTEX_INITIALIZER corresponds to an initialized, unlocked mutex with default attributes. The advantage of this is that mutexes can be used in places where malloc() calls are prohibited (such as in signal handlers and within malloc() itself). On the other hand, you can't change the size of that struct without breaking binary compatibility. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-threads@FreeBSD.ORG Sat Mar 13 03:27:17 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 021D116A4CE for ; Sat, 13 Mar 2004 03:27:17 -0800 (PST) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B92F43D1D for ; Sat, 13 Mar 2004 03:27:16 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.203.8) by smtp02.syd.iprimus.net.au (7.0.024) id 402CF870008EA6D1 for threads@freebsd.org; Sat, 13 Mar 2004 22:27:14 +1100 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id C586841C0; Sat, 13 Mar 2004 22:27:19 +1100 (EST) Date: Sat, 13 Mar 2004 22:27:19 +1100 From: Tim Robbins To: threads@freebsd.org Message-ID: <20040313112719.GA18628@cat.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: RFC: getc() and putc() as macros X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2004 11:27:17 -0000 The patch below re-adds macro versions of getc(), getchar(), putc(), putchar(), feof(), ferror(), fileno() and clearerr(), using the value of __isthreaded to decide between the fast inline single-threaded code and the more general function equivalent (as suggested by Alfred). Is this approach safe? The justification for wanting to do this is that the the performance benefits for single-threaded applications that make heavy use of these functions is pretty amazing (only 5% slower than RELENG_4). There is going to be a minor performance hit for threaded applications, but the time taken to test __isthreaded is likely to be miniscule compared to the function call and locking overhead. ==== //depot/user/tjr/freebsd-tjr/src/include/stdio.h#3 (text+ko) ==== @@ -416,6 +416,22 @@ #define __sclearerr(p) ((void)((p)->_flags &= ~(__SERR|__SEOF))) #define __sfileno(p) ((p)->_file) +extern int __isthreaded; + +#define feof(p) (!__isthreaded ? __sfeof(p) : feof(p)) +#define ferror(p) (!__isthreaded ? __sferror(p) : ferror(p)) +#define clearerr(p) (!__isthreaded ? __sclearerr(p) : clearerr(p)) + +#if __POSIX_VISIBLE +#define fileno(p) (!__isthreaded ? __sfileno(p) : fileno(p)) +#endif + +#define getc(fp) (!__isthreaded ? __sgetc(fp) : getc(fp)) +#define putc(x, fp) (!__isthreaded ? __sputc(x, fp) : putc(x, fp)) + +#define getchar() getc(stdin) +#define putchar(x) putc(x, stdout) + #if __BSD_VISIBLE /* * See ISO/IEC 9945-1 ANSI/IEEE Std 1003.1 Second Edition 1996-07-12 ==== //depot/user/tjr/freebsd-tjr/src/lib/libc/stdio/feof.c#2 (text+ko) ==== @@ -45,12 +45,8 @@ #include "un-namespace.h" #include "libc_private.h" -/* - * feof has traditionally been a macro in . That is no - * longer true because it needs to be thread-safe. - * - * #undef feof - */ +#undef feof + int feof(FILE *fp) { ==== //depot/user/tjr/freebsd-tjr/src/lib/libc/stdio/ferror.c#2 (text+ko) ==== @@ -45,12 +45,8 @@ #include "un-namespace.h" #include "libc_private.h" -/* - * ferror has traditionally been a macro in . That is no - * longer true because it needs to be thread-safe. - * - * #undef ferror - */ +#undef ferror + int ferror(FILE *fp) { ==== //depot/user/tjr/freebsd-tjr/src/lib/libc/stdio/fileno.c#2 (text+ko) ==== @@ -45,12 +45,8 @@ #include "un-namespace.h" #include "libc_private.h" -/* - * fileno has traditionally been a macro in . That is - * no longer true because it needs to be thread-safe. - * - * #undef fileno - */ +#undef fileno + int fileno(FILE *fp) { ==== //depot/user/tjr/freebsd-tjr/src/lib/libc/stdio/getc.c#2 (text+ko) ==== @@ -46,6 +46,8 @@ #include "libc_private.h" #include "local.h" +#undef getc + int getc(FILE *fp) { ==== //depot/user/tjr/freebsd-tjr/src/lib/libc/stdio/getchar.c#4 (text+ko) ==== @@ -40,9 +40,6 @@ #include __FBSDID("$FreeBSD: src/lib/libc/stdio/getchar.c,v 1.11 2004/03/10 10:24:15 tjr Exp $"); -/* - * A subroutine version of the macro getchar. - */ #include "namespace.h" #include #include "un-namespace.h" @@ -51,6 +48,9 @@ #undef getchar +/* + * A subroutine version of the macro getchar. + */ int getchar() { ==== //depot/user/tjr/freebsd-tjr/src/lib/libc/stdio/putc.c#2 (text+ko) ==== @@ -46,14 +46,8 @@ #include "local.h" #include "libc_private.h" -/* - * putc has traditionally been a macro in . That is no - * longer true because POSIX requires it to be thread-safe. POSIX - * does define putc_unlocked() which is defined as a macro and is - * probably what you want to use instead. - * - * #undef putc - */ +#undef putc + int putc(c, fp) int c; ==== //depot/user/tjr/freebsd-tjr/src/lib/libc/stdio/putchar.c#2 (text+ko) ==== @@ -46,14 +46,8 @@ #include "local.h" #include "libc_private.h" -/* - * putchar has traditionally been a macro in . That is no - * longer true because POSIX requires it to be thread-safe. POSIX - * does define putchar_unlocked() which is defined as a macro and is - * probably what you want to use instead. - * - * #undef putchar - */ +#undef putchar + /* * A subroutine version of the macro putchar */ From owner-freebsd-threads@FreeBSD.ORG Sat Mar 13 07:05:16 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 375D616A4CE; Sat, 13 Mar 2004 07:05:16 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9FB8C43D1D; Sat, 13 Mar 2004 07:05:15 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2DF5EW7006945; Sat, 13 Mar 2004 10:05:14 -0500 (EST) Date: Sat, 13 Mar 2004 10:05:14 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Tim Robbins In-Reply-To: <20040313112719.GA18628@cat.robbins.dropbear.id.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: RFC: getc() and putc() as macros X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Mar 2004 15:05:16 -0000 On Sat, 13 Mar 2004, Tim Robbins wrote: > The patch below re-adds macro versions of getc(), getchar(), putc(), > putchar(), feof(), ferror(), fileno() and clearerr(), using the value of > __isthreaded to decide between the fast inline single-threaded code and > the more general function equivalent (as suggested by Alfred). Is this > approach safe? I don't really like this. It exposes __isthreaded and others that are implementation. -- Dan Eischen From owner-freebsd-threads@FreeBSD.ORG Sat Mar 13 16:23:19 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E0B216A4CE; Sat, 13 Mar 2004 16:23:19 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0170D43D2D; Sat, 13 Mar 2004 16:23:19 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id CC2402A925; Sat, 13 Mar 2004 16:23:18 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 1D5FAE259; Sat, 13 Mar 2004 16:23:18 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i2E0MiIN001840; Sat, 13 Mar 2004 16:22:44 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i2E0MhaK001839; Sat, 13 Mar 2004 16:22:43 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-threads@freebsd.org Date: Sat, 13 Mar 2004 16:22:43 -0800 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403131622.43705.peter@wemm.org> cc: threads@freebsd.org Subject: Re: RFC: getc() and putc() as macros X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2004 00:23:19 -0000 On Saturday 13 March 2004 07:05 am, Daniel Eischen wrote: > On Sat, 13 Mar 2004, Tim Robbins wrote: > > The patch below re-adds macro versions of getc(), getchar(), > > putc(), putchar(), feof(), ferror(), fileno() and clearerr(), using > > the value of __isthreaded to decide between the fast inline > > single-threaded code and the more general function equivalent (as > > suggested by Alfred). Is this approach safe? > > I don't really like this. It exposes __isthreaded and others > that are implementation. I thought that was the kind of thing that _REENTRANT or _THREAD_SAFE are usually for? (*shudder*) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Sat Mar 13 16:23:19 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E0B216A4CE; Sat, 13 Mar 2004 16:23:19 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0170D43D2D; Sat, 13 Mar 2004 16:23:19 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id CC2402A925; Sat, 13 Mar 2004 16:23:18 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id 1D5FAE259; Sat, 13 Mar 2004 16:23:18 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i2E0MiIN001840; Sat, 13 Mar 2004 16:22:44 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i2E0MhaK001839; Sat, 13 Mar 2004 16:22:43 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-threads@freebsd.org Date: Sat, 13 Mar 2004 16:22:43 -0800 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403131622.43705.peter@wemm.org> cc: threads@freebsd.org Subject: Re: RFC: getc() and putc() as macros X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2004 00:23:19 -0000 On Saturday 13 March 2004 07:05 am, Daniel Eischen wrote: > On Sat, 13 Mar 2004, Tim Robbins wrote: > > The patch below re-adds macro versions of getc(), getchar(), > > putc(), putchar(), feof(), ferror(), fileno() and clearerr(), using > > the value of __isthreaded to decide between the fast inline > > single-threaded code and the more general function equivalent (as > > suggested by Alfred). Is this approach safe? > > I don't really like this. It exposes __isthreaded and others > that are implementation. I thought that was the kind of thing that _REENTRANT or _THREAD_SAFE are usually for? (*shudder*) -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Sat Mar 13 16:33:42 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF0CB16A4CE; Sat, 13 Mar 2004 16:33:42 -0800 (PST) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A88043D39; Sat, 13 Mar 2004 16:33:42 -0800 (PST) (envelope-from peter@evilpete.dyndns.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 54E9B2A925; Sat, 13 Mar 2004 16:33:42 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id BD215E259; Sat, 13 Mar 2004 16:33:41 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.12.11/8.12.11) with ESMTP id i2E0X8qs002025; Sat, 13 Mar 2004 16:33:08 -0800 (PST) (envelope-from peter@overcee.wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.12.11/8.12.11/Submit) id i2E0X8Y3002024; Sat, 13 Mar 2004 16:33:08 -0800 (PST) (envelope-from peter) From: Peter Wemm To: freebsd-threads@freebsd.org Date: Sat, 13 Mar 2004 16:33:08 -0800 User-Agent: KMail/1.6 References: <40441A7E.7000805@freebsd.org> In-Reply-To: <40441A7E.7000805@freebsd.org> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200403131633.08193.peter@wemm.org> Subject: Re: threads stress test X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2004 00:33:42 -0000 On Monday 01 March 2004 09:24 pm, Peter Grehan wrote: > I've been using the ping-pong test program described in: > > http://wwws.sun.com/software/whitepapers/solaris9/multithread.pdf > > to test out Suleiman Souhal's PPC libthr patches. > > I just took out sledge (AMD64) with this when linking against > libpthread and running with '-v -i 10000'. Not sure if it happens > on i386, but maybe KSE developers might want to give it a try. > Source is at: > > http://www.freebsd.org/~grehan/pp.c I just tried this and haven't been able to break it anything with it.. even on sledge. Can you still do it? -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-threads@FreeBSD.ORG Sat Mar 13 16:59:09 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C95616A4CE; Sat, 13 Mar 2004 16:59:09 -0800 (PST) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43F2943D1F; Sat, 13 Mar 2004 16:59:08 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.204.88) by smtp01.syd.iprimus.net.au (7.0.024) id 402BA92700A06F26; Sun, 14 Mar 2004 11:59:06 +1100 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 4C8E541BA; Sun, 14 Mar 2004 11:59:25 +1100 (EST) Date: Sun, 14 Mar 2004 11:59:25 +1100 From: Tim Robbins To: Peter Wemm Message-ID: <20040314005925.GA21214@cat.robbins.dropbear.id.au> References: <200403131622.43705.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403131622.43705.peter@wemm.org> User-Agent: Mutt/1.4.1i cc: threads@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: RFC: getc() and putc() as macros X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2004 00:59:09 -0000 On Sat, Mar 13, 2004 at 04:22:43PM -0800, Peter Wemm wrote: > On Saturday 13 March 2004 07:05 am, Daniel Eischen wrote: > > On Sat, 13 Mar 2004, Tim Robbins wrote: > > > The patch below re-adds macro versions of getc(), getchar(), > > > putc(), putchar(), feof(), ferror(), fileno() and clearerr(), using > > > the value of __isthreaded to decide between the fast inline > > > single-threaded code and the more general function equivalent (as > > > suggested by Alfred). Is this approach safe? > > > > I don't really like this. It exposes __isthreaded and others > > that are implementation. > > I thought that was the kind of thing that _REENTRANT or _THREAD_SAFE > are usually for? (*shudder*) Not anymore - we have to check at runtime. Tim From owner-freebsd-threads@FreeBSD.ORG Sat Mar 13 16:59:09 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C95616A4CE; Sat, 13 Mar 2004 16:59:09 -0800 (PST) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43F2943D1F; Sat, 13 Mar 2004 16:59:08 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.204.88) by smtp01.syd.iprimus.net.au (7.0.024) id 402BA92700A06F26; Sun, 14 Mar 2004 11:59:06 +1100 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 4C8E541BA; Sun, 14 Mar 2004 11:59:25 +1100 (EST) Date: Sun, 14 Mar 2004 11:59:25 +1100 From: Tim Robbins To: Peter Wemm Message-ID: <20040314005925.GA21214@cat.robbins.dropbear.id.au> References: <200403131622.43705.peter@wemm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200403131622.43705.peter@wemm.org> User-Agent: Mutt/1.4.1i cc: threads@freebsd.org cc: freebsd-threads@freebsd.org Subject: Re: RFC: getc() and putc() as macros X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2004 00:59:09 -0000 On Sat, Mar 13, 2004 at 04:22:43PM -0800, Peter Wemm wrote: > On Saturday 13 March 2004 07:05 am, Daniel Eischen wrote: > > On Sat, 13 Mar 2004, Tim Robbins wrote: > > > The patch below re-adds macro versions of getc(), getchar(), > > > putc(), putchar(), feof(), ferror(), fileno() and clearerr(), using > > > the value of __isthreaded to decide between the fast inline > > > single-threaded code and the more general function equivalent (as > > > suggested by Alfred). Is this approach safe? > > > > I don't really like this. It exposes __isthreaded and others > > that are implementation. > > I thought that was the kind of thing that _REENTRANT or _THREAD_SAFE > are usually for? (*shudder*) Not anymore - we have to check at runtime. Tim From owner-freebsd-threads@FreeBSD.ORG Sat Mar 13 17:07:57 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4577B16A4CE for ; Sat, 13 Mar 2004 17:07:57 -0800 (PST) Received: from smtp01.syd.iprimus.net.au (smtp01.syd.iprimus.net.au [210.50.30.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 15F9243D1D for ; Sat, 13 Mar 2004 17:07:57 -0800 (PST) (envelope-from tim@robbins.dropbear.id.au) Received: from robbins.dropbear.id.au (210.50.204.88) by smtp01.syd.iprimus.net.au (7.0.024) id 402BA92700A07AFD; Sun, 14 Mar 2004 12:07:55 +1100 Received: by robbins.dropbear.id.au (Postfix, from userid 1000) id 2CE1B4193; Sun, 14 Mar 2004 12:08:05 +1100 (EST) Date: Sun, 14 Mar 2004 12:08:05 +1100 From: Tim Robbins To: Daniel Eischen Message-ID: <20040314010805.GA21447@cat.robbins.dropbear.id.au> References: <20040313112719.GA18628@cat.robbins.dropbear.id.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: threads@freebsd.org Subject: Re: RFC: getc() and putc() as macros X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2004 01:07:57 -0000 On Sat, Mar 13, 2004 at 10:05:14AM -0500, Daniel Eischen wrote: > On Sat, 13 Mar 2004, Tim Robbins wrote: > > > The patch below re-adds macro versions of getc(), getchar(), putc(), > > putchar(), feof(), ferror(), fileno() and clearerr(), using the value of > > __isthreaded to decide between the fast inline single-threaded code and > > the more general function equivalent (as suggested by Alfred). Is this > > approach safe? > > I don't really like this. It exposes __isthreaded and others > that are implementation. Can you think of a better way? Tim From owner-freebsd-threads@FreeBSD.ORG Sat Mar 13 21:53:57 2004 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3487616A4CE; Sat, 13 Mar 2004 21:53:57 -0800 (PST) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id C452F43D1D; Sat, 13 Mar 2004 21:53:56 -0800 (PST) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id i2E5rtW7001969; Sun, 14 Mar 2004 00:53:55 -0500 (EST) Date: Sun, 14 Mar 2004 00:53:55 -0500 (EST) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Tim Robbins In-Reply-To: <20040314010805.GA21447@cat.robbins.dropbear.id.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: RFC: getc() and putc() as macros X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Mar 2004 05:53:57 -0000 On Sun, 14 Mar 2004, Tim Robbins wrote: > On Sat, Mar 13, 2004 at 10:05:14AM -0500, Daniel Eischen wrote: > > > On Sat, 13 Mar 2004, Tim Robbins wrote: > > > > > The patch below re-adds macro versions of getc(), getchar(), putc(), > > > putchar(), feof(), ferror(), fileno() and clearerr(), using the value of > > > __isthreaded to decide between the fast inline single-threaded code and > > > the more general function equivalent (as suggested by Alfred). Is this > > > approach safe? > > > > I don't really like this. It exposes __isthreaded and others > > that are implementation. > > Can you think of a better way? I think it was I that got rid of the macros for getc() et al. I did it when libc_r was divorced from libc, and the macro _THREAD_SAFE was no longer necessary. Solaris uses _REENTRANT to toggle between macros and functions. For the macro versions, it accesses the FILE directly instead of making a function call. I think the _unlocked versions of the functions are there for a reason. If an application isn't going to be threaded, then it can always use the unlocked versions... -- Dan Eischen