Date: Wed, 19 Jan 2000 13:09:52 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Jason Evans <jasone@canonware.com> Cc: obrien@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. Message-ID: <Pine.SUN.3.91.1000119130152.4798A-100000@pcnet1.pcnet.com> In-Reply-To: <20000119093341.M27689@sturm.canonware.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Jan 2000, Jason Evans wrote:
> On Wed, Jan 19, 2000 at 12:21:50PM -0500, Daniel Eischen wrote:
> > 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.
Well, before all blocking system calls were renamed to _thread_sys_XXX(),
so that the threads library could perform the call conversion. You'd have
to revert back to this method, and have libc_r provide routines XXX (which
are cancellable, and call _XXX), and _XXX (which does any necessary
call conversion/bookkeeping, perhaps calling _thread_sys_XXX).
Dan Eischen
eischen@vigrid.com
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?Pine.SUN.3.91.1000119130152.4798A-100000>