native threads

David Shaffer cdshaffer at acm.org
Thu Apr 14 15:37:15 UTC 2005


Ramiro Diaz Trepat wrote:

>I was just told by a co-worker that saw my previous post, that
>preemption "sort-of" exists in Squeak, but not among processes of the
>same priority, and that that was the reason why the Processor yield
>was necessary in that example.  Is this so?
>Why is preemption limited to processes of different priorities?
>Why does Morphic freeze everytime a program does something wrong? 
>Because of a poor implementation of the message queue?
>...I still think that native threads should be implemented.
>
>
>  
>
I don't necessarily disgaree with you but I'd like to point out some
somewhat obvious important facts:

    1) "green threads" have the same threading semantics across all
platforms, native threads do not.  The Java mapping of Java threads on
to OS threads is not platform agnostic therefore multithreaded Java apps
may behave differently on different platforms.  This can be a
significant problem.  Squeak (and VisualWorks) multi-threaded
applications run the same on all platforms.

    2) I've used Squeak servers in many forms and never written a single
explicit yield.  Almost every chore that a server might perform requires
it to wait on a semaphore at some point or another: socket I/O and file
I/O being the most common.  Once the thread is blocked, other threads of
the same priority can run.  The only time you get in trouble is when you
server's work is compute intensive (like generating a large image). 
Comanche, for example, will be unresponsive (queue incoming connections
but not produce responses) during such compute intensive processes.  I
can see cases where those would occur and quite often there are obvious
ways to deal with it: fork the computation of the image as a lower
priority process and then block on a semaphore until it is complete. 
This is so absolutely simple in Smalltalk that I don't even blink
suggesting it.  Really, green threads are not a problem for a server.

David





More information about the Squeak-dev mailing list