To: Greg Hudson <ghudson@MIT.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 "Sun, 10 Dec 1995 23:19:08 EST."
             <199512110419.XAA05767@lola-granola.MIT.EDU> 
Date: Mon, 11 Dec 1995 21:35:26 -0500
Message-Id: <22335.818735726@BALVENIE.PDL.CS.CMU.EDU>
From: Chris G Demetriou <Chris_G_Demetriou@BALVENIE.PDL.CS.CMU.EDU>
Sender: owner-netbsd-developers@NetBSD.ORG
Precedence: first-class

Greg said:
> > I got the following back, and am forwarding it with permission.  Any
> > comments?  I've thought for a while that, as long as it doesn't cost
> > much, making thread-safe versions of various libraries the _default_
> > is a good idea...
> 
> The show-stopper here is getc().  POSIX.1c requires that getc() and
> putc() be thread-safe (getc_unlocked() and putc_unlocked() being the
> fast versions), which makes them a great deal slower than they are
> now.  In particular, the following statement is not correct:
> 
> > I'm still trying to persuade J.T. to change NetBSD's errno
> > implementation to call __error so that all libraries built with
> > NetBSD can be linked into a threaded program.
> 
> (It may be good enough to have "everything but getc" work in most
> libraries, but it still won't be POSIX.1c-compliant.  However, note
> that making errno call __errno() will result in programs which won't
> interoperate with older versions of libc; doing that for the sake of
> an imperfect solution seems poor.)

uh, some questions about this:

	(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...)

	(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?

> Some of the statements Birrell made about Provenzano's pthreads
> package are outdated (system calls returning -errno), wrong
> (scheduling being spread out across libc functions), or indicative of
> a lack of understanding of the design goals (the need for a
> translation table between application and kernel file descriptors; the
> requirement that much of libc be reimplemented to be thread-safe).

OK, that's good to know.


Btw: i don't particularly like the idea of mandating weak references,
to support threads.  (I can accept weak references as being necessary
for standards conformance, because the ports that don't have them are
likely not in the state where it matters anyway...  however, threads
are much more useful, potentially, and I can't see a concrete need why
they'd need weak references...  anybody?)


chris