From owner-freebsd-hackers Thu Jan 13 15: 1:13 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id D6AC8151E7 for ; Thu, 13 Jan 2000 15:01:04 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id SAA08773; Thu, 13 Jan 2000 18:00:45 -0500 (EST) Date: Thu, 13 Jan 2000 18:00:45 -0500 (EST) From: Daniel Eischen To: Jason Evans Cc: hackers@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile In-Reply-To: <20000113135010.L302@sturm.canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 13 Jan 2000, Jason Evans wrote: > On Thu, Jan 13, 2000 at 07:18:12AM -0500, Daniel Eischen wrote: > > > Consider as an example that open() is a thread cancellation point according > > > to POSIX. If libpthread overrides the libc open() with its own version of > > > open(), then by extension, every function that calls open() can potentially > > > cause thread cancellation. This propagation of cancellation points is > > > legal in a specified list of libc functions, but POSIX also says that *no* > > > functions not in that list may act as cancellation points. That means that > > > we have to be absolutely sure not to propagate cancellation points within > > > libc, and short of constructing and analyzing a full call graph of the libc > > > internals, this is the only way (that I can think of) to assure that libc > > > doesn't incorrectly propagate cancellation points. > > > > Use _open internally within libc and libpthread. Have one "open" > > entry point that is the cancellation version of open. > > It isn't adequate to only have two names with a libpthread. There has to > be: > > 1) _open() -- A name to access the actual system call. > > 2) _libc_open() -- A name that libc uses internally which by default is the > same as _open(), but can be overridden. I don't think we need 2) > > 3) open() -- The name that an application uses (and cancellation point). > > As mentioned in my previous email, if we were to remove _libc_open() and > use open() instead inside of libc, we would incorrectly propagate > cancellation points. Right, use _open instead. > > If we were to remove _libc_open() and use _open() instead inside of libc, > then we would have the problem of some libc functions using system calls > directly, where libpthread needs to do call conversion and/or extra > bookkeeping work. (I experienced this problem in tests first-hand while > doing the conversion; hence the renaming of functions in libc_r.) Forget about libc_r for the moment. It's on it's last breath. Think about the thread system proposed in -arch. It is OK to have libc make system calls directly, because when they block, you'll get an upcall in another context when libpthread is linked in. If libpthread isn't linked in, then the call just blocks. Having _libc_open() used internally within libc doesn't allow libpthread to override _libc_open() because the linker has already resolved references to _libc_open() within libc to the _libc_open() that is in libc, not the _libc_open() in libpthread. Boy, that looks and sounds awfully strange as I re-read it ;-) I think you'd have to modify the linker to make this work the way you envision - jdp could tell you better. > > We can argue about names, but I don't see any way to get around having > three names. That said, I get momentarily confused about this every time I > have to think about it, so if I'm really missing something, please help me > to figure it out. =) I know, it confuses me a bit too ;-) I'm not 100% sure of the way the linker works, but my [last] understanding was that references to weak symbols within libc, would be resolved to libc, and that you couldn't override these from another library (libpthread). I hope that I'll be corrected if I've got this wrong. I'm not sure that it matters much anyways, because we don't need to override references to blocking system calls (at least with the proposed threading architecture). Some things will need to be overridden, though, such as locking mechanisms. I noticed that Solaris has all the pthread mutex/condvar calls in libc, and they're all weak symbols. They must be null bodies because if you write a program to lock a mutex twice (without linking in libpthread), you don't get an error and it doesn't hang on the second lock attempt. > > > How are you going to handle locking inside libc, if the locking > > functions are not inside libc? > > I dunno. =) Seriously, I haven't given much thought to this yet, and can't > claim to understand all the issues involved. I guess you'll learn :-) I can think of 2 different methods: 1. Locking routines would be fully implemented within libc. 2. Locking routines have null bodies in libc, and are implemented in libpthread, and a. Modify the linker to allow references to weak symbols within libc, to be overidden from libpthread, or b. Use function pointers to access the necessary functions which libpthread can overwrite with the fully implemented versions. I kind of like 2b because it seems easier. Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message