Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 12 Jan 2000 23:44:02 -0800
From:      Jason Evans <jasone@canonware.com>
To:        David O'Brien <obrien@NUXI.com>
Cc:        hackers@freebsd.org
Subject:   Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile
Message-ID:  <20000112234402.F302@sturm.canonware.com>
In-Reply-To: <20000112232140.G17687@dragon.nuxi.com>; from obrien@NUXI.com on Wed, Jan 12, 2000 at 11:21:41PM -0800
References:  <200001130455.UAA93546@freefall.freebsd.org> <20000112231010.E302@sturm.canonware.com> <20000112232140.G17687@dragon.nuxi.com>

next in thread | previous in thread | raw e-mail | index | archive | help
[CCed to -hackers since this may be of general interest.]

On Wed, Jan 12, 2000 at 11:21:41PM -0800, David O'Brien wrote:
> I'm still a little puzzled why every call to open got changed to
> _libc_open rather than do the magic w/in open().

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.

So, once we switch from libc_r to libpthread, we will have to implement,
for example open() and _libc_open() in libpthread, where open() tests for
cancellation, then calls into _libc_open(), which does the real work and
presumably culminates in a call to _open().  In fact, we can probably make
cancellation work correctly even in libc_r now, but I'll convert to
libpthread first (the order these things are done in doesn't matter much).

Jason


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000112234402.F302>