Date: Wed, 19 Jan 2000 23:54:21 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: eischen@vigrid.com, jasone@canonware.com Cc: current@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. Message-ID: <200001200454.XAA05264@pcnet1.pcnet.com>
next in thread | raw e-mail | index | archive | help
Jason Evans wrote:
> 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.
Or _thread_sys_open in the case of blocking system calls that
the threads library wants to wrap. This is the method that libc_r
used to use. In this case _open is a weak symbol to _thread_sys_open,
and libc_r provides _open to do the call conversion so that threads
don't block.
> 2) _libc_open() -- A name that libc uses internally which by default is the
> same as _open(), but can be overridden.
1a) _open -- A weak symbol to _thread_sys_open in the case when
building for libc_r.
>
> 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).
Again, I've never suggested this. I agree that libc needs to use
some other name than open.
>
> 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.
This is what I have suggested before. What we had before, was that
_only_ those system calls that were wrapped by libc_r (to prevent
blocking) were changed to _thread_sys_XXX. In this case, you
make _XXX a weak symbol to _thread_sys_XXX. This is similar
to having _libc_XXX as the weak symbol and _XXX as the system call.
I am just suggesting that we revert back to the previous method
of renaming only those system calls that libc_r needs to wrap to
prevent blocking. So, in the case of open:
libc:
-----
open (weak symbol to _open)
_open (system call)
libc_r:
-------
open (cancellable routine, calls _open)
_open (wrapped to prevent blocking)
_thread_sys_open (actual system call)
And in the case of lockf:
libc:
-----
lockf (weak symbol to _lockf)
_lockf (actual implementation)
libc_r:
-------
lockf (cancellable routine, calls _lockf)
_lockf (actual implemenation)
What we had before the _libc_XXX name additions would have worked
as long as all internal uses of XXX inside libc were changed to
_XXX, and, when building for libc_r, all renamed (hidden) system
calls need _XXX defined as weak symbols to _thread_sys_XXX.
My argument is that we don't need to provide weak symbols for
all the system calls, only the hidden system calls that libc_r
wraps. And, when we implement SA (or whatever we choose to call
it), we won't need any hidden system calls.
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?200001200454.XAA05264>