From owner-freebsd-hackers Fri Oct 20 06:57:14 1995 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA03437 for hackers-outgoing; Fri, 20 Oct 1995 06:57:14 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA03431 for ; Fri, 20 Oct 1995 06:57:11 -0700 Received: from time.cdrom.com (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA23944; Fri, 20 Oct 1995 06:56:31 -0700 Message-ID: <3087AA8F.2781E494@FreeBSD.org> Date: Fri, 20 Oct 1995 06:56:31 -0700 From: "Jordan K. Hubbard" X-Mailer: Mozilla 2.0b1 (X11; I; FreeBSD 2.1-STABLE i386) MIME-Version: 1.0 To: marino.ladavac@aut.alcatel.at CC: John Birrell , hackers@FreeBSD.org Subject: Re: NetBSD/FreeBSD (pthreads) References: <9510201221.AA26512@atuhc16.aut.alcatel.at> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.org Precedence: bulk marino.ladavac@aut.alcatel.at wrote: > > to be. So we changed libc to allow for threads. We build it twice, once with a > > preprocessor definition _THREAD_SAFE and once without it. For the threaded > > version, a few extra source files are compiled. We always link against libc, > > never libpthread.a and _then_ libc. The MIT implementation tries to sit on top > > of a system like FreeBSD/NetBSD. We believe that it should be part of it. Sorry, I'm coming into this late. This is interesting in that it's almost word-for-word identical to the proposal that was being floated around the table when David and I last talked to Chris Provenzano a USENIX or so back. I find it strange that they would be unreceptive now.. In any case, this was the proposal that I certainly liked best and (I think) David as well. One library without the extra bloat, another compiled to be thread safe. Fine! When can we have the diffs? :-) > > We've ported all our non-threaded code to FreeBSD (2.0.5R). With the exception > > of the function in the kernel which locates SYSVSHM segments, there were no > > problems. (NetBSD fixed SYSVSHM a few months ago. 2.0.5R behaves as NetBSD Could you perhaps elaborate on this a bit? It would certainly be good to fix any brokenness that exists in our SYSVSHM code, if it exists. > > did). We're currently writing widgets so that we don't rely on Motif. Then all > > we need is libc in FreeBSD to be ported to support pthreads and we have our > > factory process monitoring and control product ready to go under FreeBSD. Hmm! I'd be very interested to hear any reports you'd be willing to share about your customers experiences with FreeBSD and your product, when and if you have situations where they're deployed together. It's always good to know how our stuff behaves in the field! :) -- Jordan