On Wed, Apr 14, 2010 at 12:09 AM, Mike Hales <mike.hales at kscape.com> wrote:
> 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.

Hm, well I suppose if you wanted to preserve order then there would be
no need to fork would there?  Just post the requests to a
shared-queue, and have only one "worker" process which pops them off
the top and processes them.  That process is interruptible, of course,
by the process that appends new incoming requests to the bottom of the
queue.  I would think that would be much more reliable in a case where
order mattered, not to mention, more efficient..

> I agree with Eliot that VisualWorks does
> this correctly and in Squeak it's a bug.

I agree with Eliot about the merit of the approach where, when one
approach permits the other so that, effectively, both are available at
the image, but the other approach does not, that there is merit in the
approach that provides choice up in the image-level.  Given my limited
experience, however, I still cannot see a use-case where such
fine-grained control is useful, so "bug" is a stronger word than I
would know to use at this point..

 - Chris Muller