Message-Id: <199512120329.WAA06260@lola-granola.MIT.EDU>
To: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
Cc: netbsd-developers@netbsd.org, cgd@BALVENIE.PDL.CS.CMU.EDU
Subject: Re: John Birrell: Re: pthreads (?) on NetBSD/Alpha? 
In-Reply-To: Your message of "Mon, 11 Dec 1995 21:35:26 EST."
             <22335.818735726@BALVENIE.PDL.CS.CMU.EDU> 
Date: Mon, 11 Dec 1995 22:29:47 EST
From: Greg Hudson <ghudson@MIT.EDU>
Sender: owner-netbsd-developers@NetBSD.ORG
Precedence: first-class

>	(1) for the compiled version of getc and putc, is it really
>		that much extra overhead to call (null) lock/unlock
>		functions?  Don't most things use the ones in
>		stdio.h anyway?  (I do understand the need to have
>		a macro to differentiate, for those...)

The issue is with the macros, not the library functions.  John Kohl
came up with the idea of introducing a global flag to determine
whether you lock around getc() and putc(); it could be set by the
first pthread_create().  It's still a price to pay, but it's minimal.
You can also do that flag inside libc functions to decide whether or
not you need to do locking; this would be faster than weak references.

(There's a problem if you want to create a thread inside a signal
handler, but Chris Provenzano and I are pretty sure that's not a
signal-safe operation.  Some of the POSIX asynchronous I/O will
require us to set the flag as soon as the user requests asynchronous
I/O anywhere, but that's okay.)

>	(2) how does making errno call __errno() result in programs
>		which won't interoperate with older versions of libc?
>		Isn't that what library version numbers are for?
>		(in this case, as i understand it, you'd just need a
>		minor-number bump, as you're not deleting functions
>		from the library...)  I don't see this as a binary-
>		compatibility issue; how are there problems there?

You're right, this is surmountable.

So I no longer see any obstacles to making a thread-safe libc be the
default, without weak references.