Hi Jaromir,

You are right that I missed those updates in the lowSpaceWatcher method, thank you! I think I see at least one more similar slip, I'll review it more carefully before posting anything further.

Regarding protecting the #install method, I can't really think of  a case where this would be needed, but you are much closer to the issues related to process scheduling so you may be better able than me to judge. The actual failure modes associated with having two instances of LowSpaceWatcher would not be serious. Only one of the instances would be functional (if you are lucky) and the other would be harmlessly broken.

My main goal in posting this was to see if it makes the low space mechanism easier to understand and to document. I think it does help in that regard, so maybe after a bit of cleanup we can move it to trunk.

Dave


On 2024-01-29 22:04, Jaromir Matas wrote:

Hi Dave,
one more note: I tried `LowSpaceWatcher default signalLowSpace` and it looks like a few more `self`s need to be replaced with `Smalltalk` in #lowSpaceWatcher - (changeset attached).
Thanks,
Jaromir
 
 
On 29-Jan-24 1:43:15 PM, "Jaromir Matas" <mail@jaromir.net> wrote:
 
Hi Dave,
 
I like this very much. It's so much clearer what's going on!
 
A small suggestion - how about to run LowSpaceWatcher>>#install critically to avoid the (theoretical) possibility to start two low space watcher processes simultaneously?
 
(Like if you run this in the workspace:
    [LowSpaceWatcher install] fork.
    [LowSpaceWatcher install] fork
)
 
It's nothing critical but I'd like to know your opinion - please see System-jar.1446.
 
Thanks,
Jaromir
 
 
On 29-Jan-24 2:18:40 AM, lewis@mail.msen.com wrote:
 

I decided to give this idea a try, and I think that it does help with the documentation. Please try loading  System-dtl.1445 from the inbox, then evaluate "HelpBrowser openOn: LowSpaceWatcher". Let me know what you think of it :-)

Dave

 

On 2024-01-27 18:51, Jaromir Matas wrote:

Hi Dave,

Interesting, I wondered why the low space watcher doesn't have its class :)

best,
Jaromir


On 27-Jan-24 4:53:59 AM, lewis@mail.msen.com wrote:

On 2024-01-26 08:32, Taeumel, Marcel via Squeak-dev wrote:
Hi Jaromir --

What would be a good place to document the current state and intentions about low-space watcher? I mean, what would have helped you in this case?

Best,
Marcel


One way to document the low space watcher might be to turn it into a proper object with
a good class comment.

The low space watcher process is currently attached to a class variable in class
SmalltalkImage. This is reasonable and appropriate, but it would be just as reasonable
to have a LowSpaceWatcher object attached to the class variable, and let the LowSpaceWatcher
own the process and implement methods related for that process. The semaphore and
primitive calls could also move from SmalltalkImage to LowSpaceWatcher.

Class SmalltalkImage has a lot of responsibilities already, so moving the responsibility
for managing low space handling to a new class called LowSpaceWatcher might be a reasonable
thing to do. A happy side effect would be to let this new class serve as documentation for
the intended behavior of the low-space watcher process.

Dave