On Feb 5, 2022, at 11:26 AM, Marcel Taeumel <marcel.taeumel at hpi.de> wrote:
> 
> Hi Chris --
> 
> > If someone did want to automate setting this to true, what would be the best way? I thought about a "competing" #startUp: [...]
> 
> Well, if you have a server that depends on this behavior, I would add a class after ProcessorScheduler that overrides that behavior, yes. :-)
> 
> > Do we have things in the image that depend on this setting?
> 
> Everything. :-) There have been several discussions on squeak-dev during the past years. "false" is the better default here. The Bluebook did not get this one right, I am afraid.
> 
> >  "This flag persists across snapshots,stored in the image header." 
> 
> Hmm.. good question. Is this still the case? Does the OSVM set this to "true" by default depending on every image to flip it back to "false"? Eliot?

As the comment says, the setting persists in the image.  So the code to set if on every startup is unnecessary.  However, since we want the value of processPreemptionYields to be false, having the code remain has documentary benefit.

> 
> Best,
> Marcel
>> Am 04.02.2022 04:10:52 schrieb Chris Muller <asqueaker at gmail.com>:
>> 
>> Does anyone know what the purpose of this code in ProcessorScheduler class>>#startUp: is?
>> 
>>      Smalltalk processPreemptionYields ifTrue: [
>>           Smalltalk processPreemptionYields: false].
>> 
>> #processPreemptionYields: comment says 
>> 
>>      "This flag persists across snapshots,stored in the image header." 
>> 
>> but due to the above, effectively for the user, it does not.  If it was set true in the previous session, upon restarting it will be back to false.  The comment also indicates that the "default" is true (Bluebook behavior), but this code overrides that on every start up, so not really a default.
>> 
>> If someone did want to automate setting this to true, what would be the best way?  I thought about a "competing" #startUp: method in some other class, being careful to sequence it after ProcessorScheduler but.. hmm, could this code simply be removed, instead?  Do we have things in the image that depend on this setting?
>> 
>> Best,
>>   Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220205/3e4c7d73/attachment.html>