[402] in Pthreads mailing list archive
Re: LWP for Every Thread - vfork() that returns to parent immediately
daemon@ATHENA.MIT.EDU (Pete Delaney)
Fri Aug 30 07:01:50 1996
Date: Fri, 30 Aug 1996 03:33:00 -0700
From: Pete Delaney <peted@swdc.stratus.com>
To: Frank@swdc.stratus.com, Mueller <mueller@hp832.informatik.hu-berlin.de>
In-Reply-To: Mail from 'Pete Delaney <Pete.Delaney@RockyMountain.rahul.net> '
dated: Fri, 30 Aug 1996 00:26:16 -0700
Cc: pete@rm.rahul.net, pthreads@MIT.EDU
> > From Pete.Delaney@RockyMountain.rahul.net Thu Aug 29 18:26:05 1996
> > I was wondering if we might be best off by implementing a poor mans
> > LWP that is implemented like the vfork() system call in it's createing
>
> This is the SGI and Linux approach. The latter (clone sys call) may
> also give you insight on the source level on what has to be done. On
> top of this, you can build a Pthreads lib. And yes, you get rid of the
> signal handling and process blocking problems. You do pay the contex
> switch overhead.
Nice to hear that SGI and Linux hage addopted this approach.
I just did a FTP of:
ftp://src.doc.ic.ac.uk/packages/linux/slackware-3.1/source/kernel-source/v2.0/
and will see if I can find the clone() system call handler.
Do you know if NetBSD and FreeBSD made any special provisions for Pthreads?
> BTW, I forgot one item on the wish list: Don't loose signals, queue
> them (like POSIX .1b). This is essential when
> multiplexing/demultiplexing certain signals, most notably SIGARLM.
Yea I was afraid of this when I read that Signals are disabled during
thread switching. I suspect that if we implement a clone() sys call that
this won't be necessary because each clone can handle it's own signals.
I do wonder about the signal vectors. I read in "Threads Primer" that in
Sun's LWP the signal vectors are in the U block and are shared by the threads.
I assume this is the way Pthreads are but I suspect that this is more of
a inconvenience than a desirable feature. Anyway, I take it that cones will
have to distribute signal vectors to each of the clones in facilitate this
"feature". I would have perfered all signal mask and vectors to be copied
at the time of the thread_create().
Boy this pthread_afork() looks a bit odd; looks like a committee idea.
Know why this is needed. Seems Sun didn't bother to implement it. Hope
to have time this weekend to read some of Steve Kleiman's Threads Book.
> > if each thread is locked to a LWP/PID. I have to read thru the Sun stuff on
> > LWP, the GDB interface to LWP, and perhaps some of the AT&T system 5.4
> > code before going much further with it.
>
> LWPs are quite a bit more than that. And you have two level of
> scheduling. It's more felxible but more implementation work. And not
> much different in performance than the single syscall approach (see above).
Ok, I'll check out the clone() system call first. I thought I had a Sun
White Paper on LWP's but I havn't dug it up yet.
> > I thought while I'm looking at this stuff if you had some time to
> > consider this idea and get back to me about it it would be helpfull.
> > I have to read your {code, docs, and mail} and the MIT Pthreads code
> > more carefully and was wondering if your working on bringing your
> > version also up to the ISO Pthreads standard.
>
> D10 will come one day. Right now, someone at FSU is working on it. I
> don't know the latest state.
Anyway I can get in touch with them and compare the stat of the FSU
D10 with the MIT Pthreads. So far I like the GNU flavor that you did
more but it's not the ISO standard so eventually I'll need to have
the latest and greatest. Any suggestion?
> MIT Pthreads are easier to port but are also slower and contain a few
> bugs and omits on the API. I wish we had merged them at some
> point. But who wants to do the work?
I had difficulty configuring it for SunOS 4.1.2; here at work the System
Admin seem to want the system to stay on this old release. I use 4.1.3_U1
and 4.1.4 at home so I may try configuring it there. I tried changing the
configure script to accept 4.1.2 as 4.1.3 but I think it doesn't work. At
home I set up Solaris 2.5 with GDB so I can see who GDB works with Solaris
Threads and your stuff.
> > Time to get some rest. You going to be on the internet over the
> > weekend?
>
> Probably not.
>
> Good luck,
I'll keep ya posted. This evening I picked up a copy of:
"Programming with Threads"
by Steve Kleinman, Devang Shah and Bart Smaalders
from Prentice Hall (SunSoft Press)
I'm also considering getting the "Threads Primer" but it's $35
and "Programming with Threads" was $43 and I thought it was
better and newer. I'm nut sure yet on the "Threads Primer";
any opinion? Think it would it be over kill to get both? The
LWP diagram of the U-Block internals was nice but...
> --
> Frank Mueller
> Humboldt-Universitaet zu Berlin
> E-Mail : mueller@informatik.hu-berlin.de
> WWW URL: http://www.informatik.hu-berlin.de/~mueller
I've been pulled off the Pthreads for a short stint on a problem
with zombie processes being left around so it may be a short while
before I can continue on Pthreads.
-pete
