Date: Thu, 13 Jan 2000 13:50:10 -0800 From: Jason Evans <jasone@canonware.com> To: Daniel Eischen <eischen@vigrid.com> Cc: hackers@FreeBSD.ORG Subject: Re: cvs commit: src/gnu/usr.bin/cc/cc_fbsd Makefile Message-ID: <20000113135010.L302@sturm.canonware.com> In-Reply-To: <200001131218.HAA05212@pcnet1.pcnet.com>; from eischen@vigrid.com on Thu, Jan 13, 2000 at 07:18:12AM -0500 References: <200001131218.HAA05212@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000113135010.L302>