"John Macdonald" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I would like to suggest a radically different
> mechanism, that there be operators: fork, tfork, and
> cfork to split off a process, thread, or coroutine
> respectively.  (The first might be called pfork
> if we're willing to give up history for forward
> consistancy.)

Nice, but insufficiently general. I have written systems which use multiple
different thread schedulers (e.g. pthreads for preemptive; qThreads for
non-preemptive) in addition the process forking. Perhaps we just need a
single fork method, implemented polymorphically for different schedulers (or
scheduler interfaces). One scheduler could be written in terms of others: so
a thread-group could be a scheduler that keeps track of IDs, but delegates
the real work to another scheduler. (I think I could describe a coroutine as
an idiom whereby user-code becomes a thread-scheduler).

The problem I see with the general approach is that it might not make the
common cases sufficiently trivial.

Dave.


Reply via email to