Archiving information from a plugin

John M McIntosh johnmci at smalltalkconsulting.com
Tue Nov 8 18:55:46 UTC 2005


If you put a method called

startUp: resuming

on the class side of your class you will have that called
when then image is restarted, the resuming flag is:

a) resuming is true,
	when the image is being restarted after a quit, possibly on a  
different platform.

b) resuming is false,
	when the image is being restarted after a (snapshot) save

A class method startUp

Gets called when the image is being restarted (after snapshot, or  
restart after quit).


For shut down
shutDown: quitting   or
shutDown on the class side

Gets called when we shutdown. I'll note if you say on the mac if you  
choose quit from the apple menu bar only the
plugin shutdownModule logic is run, no smalltalk shutdown code will  
be run.  Choosing quit from a smalltalk menu will run the shutdown  
method.

The plugins also get called in the VM when they are loaded and   
unloaded, so the plugin
could also decide to manage data at that point. See initialiseModule,  
and shutdownModule,


Also see usage of registerExternalObject: and  
unregisterExternalObject  and say  for example
MpegFile>>fileHandle

where we stick data into the external objects table and use the  
fileHandle accessor to confirm the
external address is still valid, this attempts to ensure a stale  
memory address is not used. Also see the
class ExternalAdress which nils the handle at startup time.  Remember  
Startup for your method is invoked
against your class at somepoint in the startup process, however that  
does not preclude the ability for logic
in your class to run before startUp is invoked which is what  
MpegFile>>fileHandle is guarding against by
validating what the image sees against a table that is zeroed when  
the VM restarts. This also address issues
if you force quit an image and then restart since your shutdown code  
would not have run.




On 8-Nov-05, at 10:05 AM, Alan Sibley wrote:

> I hope this is the best mailing list for this question...
>
> I am writing a squeak plugin and have two questions.
> My plugin has internal objects that are modified by various  
> primitives.
> I would like to archive this information from one run to the next.
>
>
> A) are squeak ids passed into my plugin ("oops")... are they
>    only good for the single execution of the primitive (can
>    I save these off in the plugin... and expect to see them
>    around later?... does garbage collection move these guys?).

Yes a GC event will/could move the object. If you move the address of  
an object into C variable you cannot
expect to make another VM callback that would move or allocate  
memory. There is a call to push the address,
later pop it. But the best solution is to avoid the situation, such  
as allocating new objects before having to solidify
address of any objects.


>
> B) is there a prescribed way to archive information from a plugin
>    at "save image" time and later restore it at "load image" time?
>    My plugin can create an ascii string to store off state. I could
>    have a primitive save and restore the state... but how do I have  
> these
>    primitives called. Is there an existing hook for something like  
> this.
>
> Thanks in advance,
> Alan
>
>
>
>

--
======================================================================== 
===
John M. McIntosh <johnmci at smalltalkconsulting.com> 1-800-477-2659
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
======================================================================== 
===




More information about the Vm-dev mailing list