[Pharo-project] react on low space

Igor Stasenko siguctua at gmail.com
Wed Feb 2 04:34:38 EST 2011


On 2 February 2011 09:16, Max Leske <maxleske at gmail.com> wrote:
> Bill,
>
> I agree that it is important to at least know that there has been a low space condition. But then again, if there is a low space watcher anyway, shouldn't there be a way to register as a listener or something?
>
>

Well, take a look at OutOfMemory defaultAction,
it signals the lowSpace semaphore.
So, there a process which waiting on this semaphore, and once it
receives this signal it awakens and doing something.

And you are right, there is no way to hook into low space watcher to
include some custom handling.
So, this is a work to do.

Check the SmalltalkImage>>lowSpaceWatcher

There you can extend it by adding the LowSpaceHandler class variable,
then add an appropriate method to register handler,
 and once signal is received, send message to it, like:

LowSpaceHandler ifNotNil: [ LowSpaceHandler handleLowSpaceSignal ].

or something like that.

Also, there are a memory hogs, which almost same thing as a handler,
but a bit wrong terminology.
So, you can register some object as a memory hog:
Smalltalk memoryHogs add: myHog.

Then once signal is arrives, your memory hog will receive
#freeSomeSpace message, but it won't prevent the default UI message
from popping up, informing user that
something there is something which eats too much memory.

Also, i think that mechanism which suspends the process which made the
last memory allocation attempt is useless,  because
there is no any guarantees that exactly given process causing memory
overflow due to some runaway allocation, instead of some other one
which runs in parallel.

Btw, memoryHogs interface is BAD, because by itself it could provoke a
memory leaks.
This container should reference all hogs weakly, so an application
only need to register hogs, but don't unregister it manually,
because you can forget unregistering it, or in case of exception the
code which doing unregister can be not invoked, leaving hog hanging in
memory,
and referenced only by memoryHogs list and not by your application.

I filed the issue for this:
http://code.google.com/p/pharo/issues/detail?id=3646

>
> Igor,
>
> I haven't run your code yet but it looks exactly like what I was looking for! Thanks.
>
> Max
>
>>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-dev mailing list