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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
