From owner-freebsd-hackers Fri Oct 20 19:34:50 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id TAA29303 for hackers-outgoing; Fri, 20 Oct 1995 19:34:50 -0700 Received: from werple.net.au (0@werple.mira.net.au [203.9.190.18]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id TAA29298 for ; Fri, 20 Oct 1995 19:34:47 -0700 Received: from cimaxp1.UUCP (Ucimlogi@localhost) by werple.net.au (8.7/8.7) with UUCP id MAA05412 for hackers@freebsd.org; Sat, 21 Oct 1995 12:33:08 +1000 (EST) Message-Id: <199510210233.MAA05412@werple.net.au> X-Authentication-Warning: werple.net.au: Ucimlogi set sender to cimaxp1!jb using -f Received: by cimaxp1.cimlogic.com.au; (5.65/1.1.8.2/10Sep95-0953AM) id AA23919; Sat, 21 Oct 1995 12:36:00 +1000 From: John Birrell Subject: Re: NetBSD/FreeBSD (pthreads) To: ref.tfs.com!julian@werple.net.au (Julian Elischer) Date: Sat, 21 Oct 1995 12:35:59 +1000 (EST) Cc: hackers@freebsd.org, jb@cimlogic.com.au In-Reply-To: <199510210023.RAA01021@ref.tfs.com> from "Julian Elischer" at Oct 20, 95 05:23:53 pm X-Mailer: ELM [version 2.4 PL23] Content-Type: text Sender: owner-hackers@freebsd.org Precedence: bulk Julian, > I think that it is important that you do talk with Chris P about the Pthreads > implimentation because we don't want to have two competing camps in out system > with regards to threads.. Chris sent me mail yesterday and I have sent a reply with an explanation of some of the issues we addressed. He pointed out that POSIX requires a global set of signal handlers. I guess you'd prefer to stick as close to POSIX as you can? We can live with a global set of signal handlers (like we do with OSF/1). It just seemed nice to do it thread by thread. 8-(. > I see no reason why the libc changes can't be incorporated on one condition.. > THAT THEY CAN BE COMPILED IN A MODE THAT LEAVES THEM AS THEY ARE. Agreed. We add -D_THREAD_SAFE when we compile/assemble a threaded version. Without this, the code preprocesses to virtually the same thing. I say 'virtually' because we often change: return(foo(bar)); to ret = foo(bar); #ifdef _THREAD_SAFE something #endif return(ret); > (If this sounds like a lot of work for you, I appologise but remember > that we are all doing this as a hobby and it's no-body's job > to clean up after others..) Many of the changes to libc code are minor. I'm not sure how the man pages should document the threaded behavio[u]r though. > > and work out a common angle of attack on the problem.. > Chris is our guide on threads stuff in general but of course > anyone more active could 'take over'.. > We DO want to support pthreads (I have cthreads running at TFS) Jordan tells me that he and davidg discussed the integration of pthreads into libc with Chris at USENIX and the discussion went "almost word-for-word" like the one we're now having. 8-). -- John Birrell CIMlogic Pty Ltd jb@cimlogic.com.au 119 Cecil Street Ph +61 3 9690 9600 South Melbourne Vic 3205 Fax +61 3 9690 6650 Australia Mob +61 18 353 137