threads

[Werner Vogels <werner@freya.inesc.pt> writes:]
>I think we should give priority to real-time thread scheduling (1003.4a) over
>the implementation of traditional real-time process scheduling (1003.4). This
>off course means that we need a pthread interface to the kernel threads. If
>cut out most of the signal stuff the pthread defeinition isn't much different
>from any other thread interface, expect that it has explicit real-time
>assignment hooks.

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. Quoting from a News article
posted by Rob Pike to comp.os.research a while ago:

        "...a primitive called rfork takes an argument that specifies
        which resources a process holds are to be shared with its child
        and which are to be copied or created anew. The resources
        include memory (stack is always copied), file descriptors, file
        name space, Unix-style environment variables, etc."

If something like this were to be implemented in VSTa, and assuming that
context switch times are relatively small, wouldn't the need for threads
(mostly) go away?

                                        Mike Larson
                                        larz@world.std.com
Received on Fri Feb 25 20:15:13 1994