Re: threads

>Before too much effort is put into threads, we should consider whether
>existing mechanisms could be modified to handle (much of) the
>functionality provided by threads. Specifically, I'm thinking about
>something like the Plan 9 rfork primitive.

My view: I would want threads even in the case where we would have
rfork(), (you emulate threads on it or whatever.) and rfork would be
as efficient as promised. I use threads for a number of reasons: (1) they
allow me to think in parrallel execution of my code in a very simple
way (2) It easier for me to develop a system that allows 200.000 threads
sharing an address space than 200.000 processes leaning on the mmu for
protection sharing (3) non-realtime threads scheduling can be done in a
simple user-level package that can give the developer of the application
full control the way he wants his parralel tasks to be scheduled given
the timeslice he gets from the OS, (4) building synchronization methods
for threads are cheaper than for full processes for the same reason as (3).

Threads have been arround for a long time, we called them Tasks in ADA
and everybody was exteremely happy with them. We build some great
systems with it without anybody complaining that we actually shouldn't
use them but should fix the ADA compiler so we could have full ADA processes
(yech) communicating with each other to build parrallel applications.

Rob Pike stated that we don't understand fork() and exec(0 very well and
that that is the main reason for us not to use them. Programming with
rfork() (I've done it, I have plan9 on some local machines here) is much
more complicated then calling a simple thread create function.

My argument is that the problem is C that give us the problems here. Every
more complicated issue has to come from a library and thus provides us with
20 different options. If we would be implementing VSTa in ADA or Modula we
would just happily use threads because the language allows us to in an easy
wasy. If C threads interfaces are kept simple they can provide the same
programming support and joy of parrallelism.

Debugging threads programs is often painfull, but this is because our debuggers
are not very well suited for them. Put thread handling in there from the
beginning and you will survive very well.

--
Werner