Lex and Tim,

This particular thread was prompted by a TimeSlicer loose method in the
original LindaTalk changeset.  In adding event support to LindaTalk, I
have a Process which consumes the events out of the queue and triggers
them.  The number of Processes is dynamic and so you can send
EventTupleSpace>>#threadPoolSize: 5, and the thread pool will startup or
shutdown the right number of Processes (I really should rename the
method, do you think?).  They wait with a timeout on the internal queue
so that they occasionally wake up and see if they should still be
running.  I did not want to terminate them as they may be processing an
event.

A server/OS environment may have many pending requests but only part of
them may be able to process, so why not configure the number of
workers.  As far as locking goes, I can say that it is not advisable to
write to the Transcript window from other than the UI Process.  :)  If
you have one Process in the background that writes occasionally, that's
probably fine, but if you have many of them, your chances are higher to
see interesting behavior.

The current sortBlock checks for a priority field in the event.  I am
not currently changing the priority of the worker Process.  As far as
what priority ranges, what algorithms, etc, this is all up to
exploration, which is ultimately the point of all this.

I felt that if LindaTalk would run many Processes, then a guarantee that
the UI would still get some time, along with other lower priority
Processes, would be the least it could do to be non-intrusive.  There
are sure to be other processes that run at #userBackground that do some
calculations on a data structure that really improve its performance or
something.  I imagine that there are all kinds of interesting work that
could be done in the background.   If we are under heavy load, then it
still may make some sense to do some processing at this level.  The
thing is, I just don't know, so it all goes into the experiment bin!

thanks for helping my addled brain along!

regards,
Rob

PS.  The EventTupleSpace could perhaps be useful for security and the
Category stuff.  It could be used as a Port, like the system you
mentioned a few months back Lex (Mach? E?).  If someone could only
figure out how to ensure that your reference to the Master TupleSpace
can be made to also go through a port.

Lex Spoon wrote:
> 
> Please note that we really don't want *all* processes to get preempted.
> It is convenient most of the time that you don't get preempted by
> processes at the same priority, because it usually allows you to do
> without locks.  Processes should have to register if they want to be
> shuffled by the shuffler.
> 
> By the way, what priority should the processes get toggled to?  Perhaps
> the register method should have a parameter for the desired lower
> priority.
> 
> One final note: multiple schedulars running in the same image is bound
> to cause trouble, and yet, but is there any one schedular that will make
> everyone happy?  Why do people want preemption at all, by the way?
> 
> -Lex
> 
> Tim Rowledge <tim at sumeru.stanford.edu> wrote:
> > The canonical example of this is simply a high priority loop waiting on
> > a Delay. Each time the Delay fires it will stir up the process list at
> > the priority of the suspended process (and by extension any other
> > priority level that might get involved) assuming of course that the
> > suspend is implemented to add the suspended process at the back of the
> > list. Not all systems actually do that - VW used to put it at the front
> > of thelist and so the same process would get resumed. Might still be
> > like that for all I know.
> >
> > I think there is all the VM support you need already there, what with
> > the Delay etc. Note that checkForInterrupts is already involved since it
> > is the mechanism by which the Delay termination is noticed!
> >
> > I imagine that it might be useful to add some VM support to directly
> > deal with a special timer for process stirring and thereby reduce by a
> > small amount the allocating and setting up of actual Delay objects, but
> > it would be a pretty minimal improvement I suspect.
> > tim
> >
> > --
> > Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
> > Never write software that anthropomorphizes the machine.

-- 
--------------------------------------------------
Smalltalking by choice.  Isn't it nice to have one!