Date: Wed, 19 Jan 2000 09:33:41 -0800 From: Jason Evans <jasone@canonware.com> To: Daniel Eischen <eischen@vigrid.com> Cc: obrien@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. Message-ID: <20000119093341.M27689@sturm.canonware.com> In-Reply-To: <200001191721.MAA28462@pcnet1.pcnet.com>; from eischen@vigrid.com on Wed, Jan 19, 2000 at 12:21:50PM -0500 References: <200001191721.MAA28462@pcnet1.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Jan 19, 2000 at 12:21:50PM -0500, Daniel Eischen wrote:
> > No, I was just busy doing other things.
> >
> > There is potentially one good reason to leave these changes in place for
> > now: they allow proper thread cancellation in libc_r as it stands right
> > now. This seems to me like a good enough reason to leave the changes as is
> > until our grand new threads library is realized. However, I agree that in
> > the end we will want to simplify the libc symbol naming.
> >
> > I'm planning on checking in libc_r cancellation changes today that use the
> > current libc symbol naming setup. As soon as we're not using libc_r
> > anymore I'll be glad to simplify the symbol naming.
>
> I guess I'm confused as to why you can't do what you need with
> _XXX (internally used, non-cancellable function) and XXX (weak
> reference to _XXX) within libc. libc_r would provide XXX that
> did something along the lines of:
>
> int
> XXX(void)
> {
> enter_cancellation_point();
> _XXX();
> leave_cancellation_point();
> return(0);
> }
Doen't that method still have the problem of propagating cancellation
points within the libc code? In another email I argued for the need for
three names, and your response was that three names aren't needed in the
context of the next-generation threads library, but it seems to me that in
the case of libc_r, three names really are needed in order to do
cancellation correctly. Following is a revised version of my previous
email (changed to reflect libc_r rather than libpthread):
It isn't adequate to only have two names with libc_r. There have 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).
If we were to remove _libc_open() and use open() instead inside of libc, we
would incorrectly propagate cancellation points (as is the case right now,
since _libc_open() and open() are the same in libc_r).
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 libc_r needs to do call conversion and/or extra bookkeeping
work.
Jason
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000119093341.M27689>