From owner-freebsd-current  Wed Jan 19  9:35:18 2000
Delivered-To: freebsd-current@freebsd.org
Received: from canonware.com (canonware.com [207.20.242.18])
	by hub.freebsd.org (Postfix) with SMTP id CCEC915319
	for <current@FreeBSD.ORG>; Wed, 19 Jan 2000 09:34:59 -0800 (PST)
	(envelope-from jasone@canonware.com)
Received: (qmail 39016 invoked by uid 1001); 19 Jan 2000 17:33:41 -0000
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>
References: <200001191721.MAA28462@pcnet1.pcnet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0i
In-Reply-To: <200001191721.MAA28462@pcnet1.pcnet.com>; from eischen@vigrid.com on Wed, Jan 19, 2000 at 12:21:50PM -0500
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

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