[squeak-dev] Are Squeak processes pre-emptive?

Josh Gargus josh at schwa.ca
Wed Apr 14 22:45:48 UTC 2010

On Apr 14, 2010, at 2:56 PM, Randal L. Schwartz wrote:

>>>>>> "Chris" == Chris Muller <ma.chris.m at gmail.com> writes:
> Chris> I agree with Eliot about the merit of the approach where, when one
> Chris> approach permits the other so that, effectively, both are available at
> Chris> the image, but the other approach does not, that there is merit in the
> Chris> approach that provides choice up in the image-level.  Given my limited
> Chris> experience, however, I still cannot see a use-case where such
> Chris> fine-grained control is useful, so "bug" is a stronger word than I
> Chris> would know to use at this point..
> It would be nice to presume that if I'm running, I'll stay running,
> interrupted only by either a higher priority process, or me saying
> "yield".

Or blocking on a mutex, or waiting for bytes from a socket or a file, or etc. etc.

Why would it "be nice" to be able to presume that?  A couple of use-cases have been proposed, and upon examination, neither one is facilitated by making the presumption.  What's a concrete use-case where this scheduling behavior pays its way?  I can't think of any, but that doesn't mean they don't exist.

In my opinion, there's too many possible gotchas in this approach to rely on it as a general mechanism for managing concurrency.


More information about the Squeak-dev mailing list