From owner-freebsd-current  Wed Jan 19 20:54:34 2000
Delivered-To: freebsd-current@freebsd.org
Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3])
	by hub.freebsd.org (Postfix) with ESMTP
	id 5E6861504B; Wed, 19 Jan 2000 20:54:27 -0800 (PST)
	(envelope-from eischen@vigrid.com)
Received: (from eischen@localhost)
	by pcnet1.pcnet.com (8.8.7/PCNet) id XAA05264;
	Wed, 19 Jan 2000 23:54:21 -0500 (EST)
Date: Wed, 19 Jan 2000 23:54:21 -0500 (EST)
From: Daniel Eischen <eischen@vigrid.com>
Message-Id: <200001200454.XAA05264@pcnet1.pcnet.com>
To: eischen@vigrid.com, jasone@canonware.com
Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp.
Cc: current@FreeBSD.ORG, obrien@FreeBSD.ORG
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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