Date: Fri, 20 Oct 95 13:22:07 MET From: marino.ladavac@aut.alcatel.at To: jb%cimaxp1@werple.net.au (John Birrell) Cc: hackers@freebsd.org Subject: Re: NetBSD/FreeBSD (pthreads) Message-ID: <9510201221.AA26512@atuhc16.aut.alcatel.at> In-Reply-To: <199510200103.LAA08945@werple.net.au>; from "John Birrell" at Oct 20, 95 11:05 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > have you forwarded your changes back? > 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.) > 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]. As an example of an area where our design differs, > consider handing signals. MIT uses a global set of signal handler definitions. > We do this on a thread-by-thread basis. A thread that is interrupted by a > signal which it wants to catch, suspends while a signal-handler-thread runs. > This thread can do what it believes is blocking IO and it can catch signals > (which cause additional signal-handler-threads to run and so on). The scheduler > allows threads that are not waiting on signal handler threads to compete > against any signal-handler-threads. Our scheduler allows a context switch when > the real signal handler function is about to return. Threads are context > switched out by another thread doing blocking I/O or by a signal, the most > common of which is SIGVTALRM. > Another area where we differ from MIT, is in the use of mutexes internally > within the threaded library. We believe that mutexes are things that the > library provides, but that the low level implementation should not use them. > This means that we have stripped the malloc mutex, the file descriptor > mutexes, the key-specific mutex etc. We inhibit signals from interrupting the > scheduler in zones of code that need to be protected. This partially answers my question from another post. Please note that the MIT pthreads (recent versions thereof) do it in a similar way on a platform that does not support kernel level threads. Perhaps the use/nonuse of mutices internally should be a build-time option. > > > > are you doing this under FreeBSD as well? > We're a bit behind with FreeBSD. You guys move so quickly... 8-). > 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'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. > 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 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? /Alby > > > > julian > > > -- > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9510201221.AA26512>