From owner-freebsd-current Wed Jan 19 9:21:59 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 0F311152CE; Wed, 19 Jan 2000 09:21:57 -0800 (PST) (envelope-from eischen@vigrid.com) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id MAA28462; Wed, 19 Jan 2000 12:21:50 -0500 (EST) Date: Wed, 19 Jan 2000 12:21:50 -0500 (EST) From: Daniel Eischen Message-Id: <200001191721.MAA28462@pcnet1.pcnet.com> To: jasone@canonware.com, obrien@FreeBSD.ORG Subject: Re: RFC: buildworld breakage due to cross-tools/libc/mktemp. Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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); } Dan Eischen eischen@vigrid.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message