Date: Fri, 20 Oct 1995 11:05:29 +1000 (EST) From: John Birrell <cimaxp1!jb@werple.net.au> To: julian@ref.tfs.com (Julian Elischer) Cc: hackers@freebsd.org, jb@cimlogic.com.au Subject: Re: NetBSD/FreeBSD (pthreads) Message-ID: <199510200103.LAA08945@werple.net.au> In-Reply-To: <199510192246.PAA23918@ref.tfs.com> from "Julian Elischer" at Oct 19, 95 03:46:19 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Julian, > > > I'm curious about why you *need* kernel threads. > > usually it's for several blocking IO streams.. The user space threads implementation fudges blocking IO and this works fine for us. > > > > > If you end up trying to use the MIT threads, watch out! We ended up completely > > retructuring the code to a more sane (IMHO) implementation. > this is the stuff you ended up using right? Yes, we ended up using our restructured version. We've got a customer deadline to meet with $$$ attached, so this was an easy decision to make. > 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. 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. > > 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? > > 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?199510200103.LAA08945>