From owner-freebsd-current Wed Jan 19 10:10: 3 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 473D914FE6; Wed, 19 Jan 2000 10:10:00 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id NAA05871; Wed, 19 Jan 2000 13:09:52 -0500 (EST) Date: Wed, 19 Jan 2000 13:09:52 -0500 (EST) From: Daniel Eischen To: Jason Evans Cc: obrien@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. In-Reply-To: <20000119093341.M27689@sturm.canonware.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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