What new system calls do you want in BSD?

[brnstnd at stealth.acf.nyu.edu]

In article <131446 at sun.Eng.Sun.COM> lm at sun.UUCP (Larry McVoy) writes:
> In article <2212.21:08:11 at stealth.acf.nyu.edu> brnstnd at stealth.acf.nyu.edu (Dan Bernstein) writes:
> >In article <7848 at pt.cs.cmu.edu> dstewart at fas.ri.cmu.edu (David B Stewart) writes:
> >> How about implementing good ol' semaphores, with a much simpler interface
> >> than Sys V.
> >Actually, I just built a simple threads library on top of my signal
> >library. Everything is shared. You get threadfork(), threadexit(),
> >threadup() and threaddown() for semaphores, and a few other calls.
> 
> Yeah, I did the same thing once for kicks.  It's cute, but essentially useless.
> You don't have threadkill() or threadsignal(),

As I said, everything is shared---including signals. What's wrong with
this? As long as all the threads set up their signal handlers through my
library, they won't interfere with each other.

> but you do have 
> block_all_threads() in the form of read(), write(), select(), and any other
> system call that can block().

This is based on the faulty assumptions that I demolish in a companion
message. When an I/O system call blocks, it can be interrupted! (Larry's
point is correct for certain system calls that do not perform I/O. For
example, if you open() a pty without anyone to talk to, you'll block in
kernel mode, as ps shows.)

> Bottom line: threads without kernel support are largely useless.

Bottom line: When I'm done with the libraries I'll give them to Rich and
see whether the rest of the world thinks they're so useless.

---Dan