[squeak-dev] Are Squeak processes pre-emptive?
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
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