Say for example a server that receives network requests at a certain priority, then spawns worker processes at a lower priority. When the server receives a new request, it should interrupt the current worker process to fork another, but then the previously running worker process should continue, not be put to the back of the queue. That way worker processes can complete in the order that they were forked, not shuffled randomly to the back based on some external factor. I agree with Eliot that VisualWorks does this correctly and in Squeak it's a bug. I guess you could work around it with Semaphores, but that adds a large burden on the developer.<br>
<br clear="all">Mike Hales<br>Engineering Manager<br>KnowledgeScape<br><a href="http://www.kscape.com">www.kscape.com</a><br>
<br><br><div class="gmail_quote">On Tue, Apr 13, 2010 at 9:21 PM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">> If you have some task that is clearly higher-priority than some other task (eg: VoIP vs. polling an email server), then it's better to simply use a higher-priority Process rather than relying on particular scheduling behavior within a single priority-class.<br>
<br>
</div>Hm, agreed.. So.. what is a use-case for when you might want the type<br>
of cooperative scheduling Eliot mentioned?<br>
<br>
</blockquote></div><br>