Real-time kernel for Squeak

Ken G. Brown kbrown at tnc.com
Thu Nov 11 14:46:51 UTC 1999


It seems to me that what is really needed is a great real-time kernel 
that the Squeak community has control of and that can be optimized 
for Squeak use.
    Ken G. Brown

><>
>  > If a VM implementor wants to, they can have a thread listening
>  > on each socket so that semaphores will be signalled immediately
>  > when they become ready. I think the Mac port does so already.
>
>	The Mac does use interrupt-driven callbacks in the VM, 
>provided via MacTCP. But MacTCP is going bye-bye.
>
>  > Thus, you don't need a new primitive suite to support what you
>  > are describing, right?
>
>	Right; it only matters if you want optimal performance and 
>maximal simplicity in implementation and debugging.
>
>  > Maybe there are other reasons to have new primitives, though?
>
>	Hey, I read my mind! :)
>
>  > Also, an important question that everyone is ducking so far is,
>  > what is the *practical* difference with polling versus using OS
>  > wake-up events?
>
>	It's the *latency* associated with responding to a socket event.
>
<>





More information about the Squeak-dev mailing list