[Pharo-project] 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
good I like to see you working on that. I should get some times over the week-end to publish coral 0.1 :) Stef On Jan 8, 2010, at 5:51 PM, 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.
- 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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
Cheers, -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On Sat, Jan 9, 2010 at 01:36, John M McIntosh <johnmci@smalltalkconsulting.com> wrote:
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.
OK, makes sense -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
On Fri, Jan 08, 2010 at 04:36:17PM -0800, John M McIntosh wrote:
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
The OSPP plugin will work for both 32 bit and 64 bit VMs (32 and 64 bit images also), but you do need to have the 32 bit VM load the 32 bit OSPP, and the 64 bit VM load the 64 bit OSPP. This of course will be the case for all external plugins. Dave
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. Dave
On Sat, Jan 9, 2010 at 18:53, David T. Lewis <lewis@mail.msen.com> wrote:
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.
Thanks ! -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet
participants (4)
-
Damien Pollet -
David T. Lewis -
John M McIntosh -
Stéphane Ducasse