Problems saving the image on SIGTERM

> Hi,
>
> Chaff is a tiny class to intercept the SIGTERM signal and save the
> image http://www.squeaksource.com/Chaff.html
>
> Several problems:
>
> - OSProcess accessor forwardSigTern will only work once. Once the VM
> has registered a handler for a given signal, it can't clean it up or
> register another semaphore, until the image restarts.
>
> - If I have a process waiting on the semaphore, but the image quits
> for a different reason, I guess when it restarts, the process will
> still be there but the semaphore will be invalid… what's a good way to
> handle that ?
>
> - OSProcess does not seem to be able to register signal handlers at
> all on the Cocoa VM (5.2b9)
>
> Cheers,
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>
> Cheers,
> --
> Damien Pollet
> type less, do more [ | ] http://people.untyped.org/damien.pollet
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> Hi,
>
> Chaff is a tiny class to intercept the SIGTERM signal and save the
> image http://www.squeaksource.com/Chaff.html
>
> Several problems:
>
> - OSProcess accessor forwardSigTern will only work once. Once the VM
> has registered a handler for a given signal, it can't clean it up or
> register another semaphore, until the image restarts.

>
> On 2010-01-08, at 8:51 AM, Damien Pollet wrote:
>
> > Hi,
> > - OSProcess does not seem to be able to register signal handlers at
> > all on the Cocoa VM (5.2b9)
>
> Unless you've compiled up a OSProcess for use in 64bit mode you should have had the loading of the
> 32bit OSProcess fail.   If you are running the 5.2b9 VM in 32bit mode it *might* load the plugin, but I
> don't think I expose the argc/argv in the linker so I think the OSProcess plugin load will again fail.
>
> If you alter the info.plist and change SqueakDebug to 1 from 0 it should print a bit more info
>

> On Fri, Jan 08, 2010 at 05:51:51PM +0100, Damien Pollet wrote:
>> Hi,
>>
>> Chaff is a tiny class to intercept the SIGTERM signal and save the
>> image http://www.squeaksource.com/Chaff.html
>>
>> Several problems:
>>
>> - OSProcess accessor forwardSigTern will only work once. Once the VM
>> has registered a handler for a given signal, it can't clean it up or
>> register another semaphore, until the image restarts.
>
> Not so. The plugin allows you to reset a signal handler to its default
> value for exactly this reason. This is the method comment in
> UnixOSProcessPlugin (the part that runs in the VM):
>
> forwardSignal: sigNum toSemaphoreAt: semaphoreIndex
>        "Set a signal handler in the VM which will signal a Smalltalk semaphore at
>        semaphoreIndex whenever an external signal sigNum is received. Answer the
>        prior value of the signal handler. If semaphoreIndex is zero, the handler is
>        unregistered, and the VM returns to its default behavior for handling that
>        signal. A handler must be unregistered before it can be registered again.
>
>        The Smalltalk semaphore is expected to be kept at the same index location
>        indefinitely during the lifetime of a Squeak session. If that is not the case, the
>        handler must be unregistered prior to unregistering the Smalltalk semaphore."
>
> Thus in UnixOSProcessAccessor you have #forwardSigInt to set a handler,
> and #restoreSigInt to restore the signal handler to its default. After
> it has been restored you can set it again.
>
>> - If I have a process waiting on the semaphore, but the image quits
>> for a different reason, I guess when it restarts, the process will
>> still be there but the semaphore will be invalid??? what's a good way to
>> handle that ?
>
> The semaphore will be valid but will receive no signals from the VM.
> When you restart the image, you will need to set your signal handlers
> at that time. Most likely you will want to just start a new process,
> perhaps in a #startUp: method.