From owner-freebsd-hackers Thu Jan 13 13:50:37 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from canonware.com (canonware.com [207.20.242.18]) by hub.freebsd.org (Postfix) with SMTP id 3C6B314EA2 for ; Thu, 13 Jan 2000 13:50:35 -0800 (PST) (envelope-from jasone@canonware.com) Received: (qmail 13398 invoked by uid 1001); 13 Jan 2000 21:50:10 -0000 Date: Thu, 13 Jan 2000 13:50:10 -0800 From: Jason Evans To: Daniel Eischen Cc: hackers@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile Message-ID: <20000113135010.L302@sturm.canonware.com> References: <200001131218.HAA05212@pcnet1.pcnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001131218.HAA05212@pcnet1.pcnet.com>; from eischen@vigrid.com on Thu, Jan 13, 2000 at 07:18:12AM -0500 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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. 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. 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.) 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. =) > 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. Jason To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message