On 1-May-07, at 12:05 PM, J J wrote:

>
> At the moment, I am not looking to solve a problem per se.  I was  
> just thinking that Smalltalk tries to be it's own OS, kind of.  I  
> wonder what would happen if it went a bit further.
We did this at Interval. We could schedule Smalltalk process threads,  
native code threads, interrupt between them etc. It wasn't  easy and  
I'm not at all convinced that it was worth the work.

>
> On a real OS

...interesting definition of 'real' here. I can assure you there are  
OSs I've used that didn't do any such thing...

> , a processes are only allowed to run for a certain amount of time  
> before the CPU interupts them and puts the OS back in control to  
> decide what to do next.  In any kind of "green threads" system this  
> (normally) isn't doable because it is actually just one running  
> process and if a "green thread" doesn't want to yield, then the  
> threading system never gets back in control to stop it.  The  
> threading system could, of course, have the OS send it some kind of  
> signal ever so many milliseconds but how that is done is very  
> platform specific (not to mention a host of other problems with it).
You can easily do this in Smalltalk in a portable way; just a high  
priority process that cycles on a time interrupt to shuffle the  
process scheduler. You can manually shuffle the processes at the  
various priorities if you want to.

>
> But with an interpreter it would be possible to do the same things  
> an advanced OS does, let a process only run for a specific amount  
> of VM instructions, penilize processes that keep using their whole  
> "quantum", promote processes that don't, etc.


If you want to do some sort of count of bytecodes or prim calls  
instead of a simple timer, that is not difficult to arrange. I think  
John put some timer/counter stuff in a few years ago that would  
support this.

>
> The question is, would this have any benifit?
I'm not sure; to be honest there seems little point in trying to make  
'Smalltalk be the OS' for practical systems. What is probably much  
more sensible is to make Smalltalk do much better at integrating into  
the OS so it has more general value. In some respects Spoon is making  
a very good pass at this. The cost is that for every bit of OS  
integration you provide the cost of porting goes up enormously.

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Strange OpCodes: PBF: Pay Bus Fare