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@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@sumeru.stanford.edu, http://sumeru.stanford.edu/tim Never write software that anthropomorphizes the machine.