Ross Boylan <RossBoylan at stanfordalumni.org> wrote:

> I think I've got it.  This message is to confirm my understanding and
> answer a few questions people asked me.
Sounds like you've pretty much got it to me.
> 


> So John's  earlier statement that
> > [P]rocessing switching can occur ....
> > on a primitive call if  when the call takes > 1 or perhaps 17ms  
> > depending on platform.
> does not reflect current behavior?
Yes and no :-) For quite a long time there was code in the prim calling
routines that checked the time before calling a prim and after the
prims and if the delta was high enough it would force a process switch
check. For 3.7 I changed that to avoid the quite expensive (on some
platforms) time check and cache prim function addresses in the method
cache. As a part of that we also made it the obligation of prim writers
to think about whether their prim code could reasonably count as long
running and to call forceProcessCheck (I think) when appropriate. For
3.8 the method caching has been further extend to hold the addresses of
external/plugin functions too and so some further work will be needed
to add forceProcessCheck to some plugin prims.
But if you call a prim that takes 24 hours to run, you're SOL and
there's not much that can be done. Except of course rewriting the prim
to spawn a child process, a native thread, work via a socket or
whatever.


> 
> > > 
> > > Obviously if you have a lower priority (smalltalk) process a higher
> > > priority process can block you, but I thought the problems did not end
> > > there.  Most of the comments in this email thread indicate that the
> > > initial example of the email thread was a problem only because it was
> > > running at a relatively high priority.  But some of the comments
> > > indicate the problem is the processor (as in processor vs email, not
> > > as in the class Processor) thread is not yielding control,
> > > regardless of its priority.
> > Can't quite make out your point there, sorry.
> 
> Sorry to be unclear (Ned also couldn't follow).  Rephrasing, it's
> clear that higher priority processes can block lower priority ones.
> But I read some of the comments (e.g., the quote from Tim at the top
> of this message) as saying that a low priority process could block a
> high priority one.  My current understanding is that's not true
> (unless there's a call out or a weird bit of code without message
> sends or jumps back).
That's about it except for the long-running prims bit above.
> 
> > 
> > [snip]
> > > But below you say every method  send is an opportunity to yield, so
> > > explicitly coded yields seem unnecessary.  More about this below.
> > Recall that the process switch checking done in the VM only checks for
> > a runnable _higher_ priority process.
> 
> This clarifies something for me: although the places in which a
> process can yield occur frequently, yielding does *not* occur
> automatically to same priority processes.  This would be one reason to
> code explicit yields.
Correct.


> Was the decision not to implement a scheduling policy with ageing
> (priority drops as a process runs; it rises the longer it has not run)
> motivated by a desire for simplicity, or by some actual risks with an
> ageing policy?
Probably simplicity and 'it works ok' combined is my guess.

> 
> P.S. Multiprocessor systems are becoming increasingly common. so that
> would be one possible motivation for native threads.
Indeed it is but it's not an easy thing to do well. And native threads
don't tie in to the crucial VM invariant that process switching happens
only at bytecode and prim boundaries plus the few prims that explicitly
manipulate processes. That adds low-level complications.

My guess is that it might be more useful to be able to run micro-VMs
and pass objects around a sort of community image. Each VM would do
it's one thing and could actually drop much of the process handling to
leave it to each image to fork. That ought to be a mechanism that would
scale across threads, processes, processors and networks. 



tim
--
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
A)bort, R)etry or S)elf-destruct?