[290] in Pthreads mailing list archive
Re: What's going on with MIT pthreads?
daemon@ATHENA.MIT.EDU (Greg Hudson)
Wed Mar 13 13:10:38 1996
To: "William S. Gribble" <grib@cs.utexas.edu>
Cc: pthreads@MIT.EDU
In-Reply-To: Your message of "Wed, 13 Mar 1996 11:31:43 CST."
<199603131731.LAA22878@cascade.cs.utexas.edu>
Date: Wed, 13 Mar 1996 12:44:28 EST
From: Greg Hudson <ghudson@MIT.EDU>
> If work is still being done, where's it heading?
Right now, we're mostly working on stability issues prior to the 1.60
release. In theory, we will be moving towards kernel threads support
(a hybrid scheduling module) in a 1.70 release.
> Getting a newer version incorporated into Linux libc?
This will have to happen on HJ's initiative.
> A good c++ binding?
pthreads is intended to be a good implementation of the POSIX.1c
standard with a few added features. I don't think we want to get into
defining our own C++ interface. At any rate, the concepts are so
simple that it's trivial to define your own.
> The remaining problems I have with the 4_1 release I haven't been
> able to precisely pin down, but they're related to signals. There
> are conditions where signals just get dropped on the floor.. it
> happens semi-reliably when all threads are blocked on I/O or
> sleeping. Have other people had this problem?
If you have no threads to dliver a signal to, they will wait until a
thread is available. This may or may not be required by the standard;
I've gotten a bit lost in all the proposed and finalized amendments.
At any rate, I believe Chris recently checked in a change to make ^C
abort the process if no threads are running and ^C has no signal
option, which was the biggest problem.
