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,JaromirOn 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
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