Date: Fri, 20 Oct 1995 17:23:53 -0700 (PDT) From: Julian Elischer <julian@ref.tfs.com> To: marino.ladavac@aut.alcatel.at Cc: jb%cimaxp1@werple.net.au, hackers@FreeBSD.org, proven@FreeBSD.org Subject: Re: NetBSD/FreeBSD (pthreads) Message-ID: <199510210023.RAA01021@ref.tfs.com> In-Reply-To: <9510201221.AA26512@atuhc16.aut.alcatel.at> from "marino.ladavac@aut.alcatel.at" at Oct 20, 95 01:22:07 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> John Birrell says: [lots'o'stuff] > 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.. 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. (or provably equivalent) man pages MUST be updated to match the changes.. (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..) As I said to the guys doing IPX support, I'm willing to import code that I don't have to do massive work on myself, and for which there has been sufficient scrutiny. I consider the blessings of any two of phk, jkh, davidg, dyson, bde or me as suffient (if I can get time to look at it) One ther thing I want is that various camps working on related items need to talk and send me a note that they have looked at each other's work, and that they have either: worked out a common set of patches, or worked out an agreed strategy for co-existance. under these guidelines: I'm willing to commit your changes if: you can talk to Cris P Login: proven@freebsd.org Name: Chris Provenzano Directory: /home/proven Shell: /bin/csh Office: PROVEN Last login Wed Oct 18 09:16 (PDT) on ttyp8 from JIMI.MIT.EDU No Mail. Mail forwarded to: proven@athena.mit.edu 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) you might also want to talk to rminnich@Sarnoff.COM with regards to his rfork stuff.. I think it could be used to give a nice kernel threads/user-threads mix.. > > > No. Instead I've started talking to a few NetBSD folks about making libc > > support pthreads directly. The MIT implementation has duplicated _many_ of > > the libc functions, including the assembly language stuff like setjmp. This > > makes supporting the system (pthreads + opsys) more difficult than it needs > > 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. > > Amen! Or at least parallel to libc, on the same level (similar to libcrypt > approach.) I'd support it IN libc if it were optional but a parallel library made from the same sources would be as good.. > > > Our implementation is now so different to the one from MIT that I doubt they'd > > be receptive to changes that affect their basic design. [Sorry if I have jumped > > to the wrong conclusion]. I think it's important that you talk to ChrisP. I'd like to support you, but if I do it mustn't exclude what he's doing.. it might even be possible for him to see the benefits in what you've done.. > > We're a bit behind with FreeBSD. You guys move so quickly... 8-). you should get a sup feed of the cvs tree for the kernel and libc if you plan on doing this.. > > > 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 > > did). We wil accept patches to fix this relative to 2.2-current sources if you are able to submit them.. We want to support our users.. but we can't find all the fixes ourselves. > > Are you prepared to consider changing the FreeBSD libc to allow the _option_ > > of building a threaded version? Do you prefer keeping a separate libpthread > > like MIT builds? Are you using the MIT pthreads under FreeBSD? I'm not using them but I believe several people are. some libc fixes come under "General multithreading improvements" and can definitly go straight into libc. maybe we might have to have two subsiduary libraries libmitpthreads.a ;) and lib???pthreads.a possibly built from the same sources with different compile options.. > > I can speak only of myself, as I am definitely no project member. Yes, I do. > I would also be very interested in making the FreeBSD libc thread safe or > multithreaded as well. Keeping the library parallel but separate from libc > has its own merits, though. Especially during development thereof. > > Any (other) takers? I'll support it for sure. but I can't do the work, just act as source tree contact. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510210023.RAA01021>