djantzen has asked for the wisdom of the Perl Monks concerning the following question:

Some time ago I wrote a set of modules to handle future events in a Web publishing system. The idea was to create an object that would represent an action, call it a ‘Job’, associate a timespec with it for when it should be executed, freeze it using the Storable module, and then write it to an Oracle CLOB (Character Large Object) column. When the specified time rolled around, the object would be revived, and the instructions contained therein executed.

The current system works okay, but not great, and the recent discussions of closures here (What's a closure?,Why are closures cool?) got me thinking that what I really want to do is to serialize a closure for execution at a later time. (Actually, in most cases a proper closure won’t be necessary, a normal CODE reference will suffice.) My hopes were dashed however, as I discovered in my test code that Storable refuses to work with CODE references, and sure enough the documentation says:

You can’t store GLOB, CODE, FORMLINE, etc... If you can define seman +tics for those operations, feel free to enhance Storable so that it can deal with them.

So, short of learning XS and hacking those 4,000 or so lines of C underneath Storable, the closest I can get to this is to store the subroutine in plain text and eval it later. As in:

my $code = q( sub { my ($x, $y); doSomeStuff($x, $y); } ); my $sub = eval ($code);

This will do the trick for me most of the time, however I’d like to hear some thoughts on the issues and difficulties in defining a semantics for serializing CODE references. It is evident to me now that serializing proper closures would be insanely difficult, and indeed futile given that the point of serialization is to preserve a data structure between processes, making it a “pass-by-value” activity, and closures involve references to lexical variables from the scope within which the subroutine is defined. However, I don’t yet see why generating a semantics for normal CODE refs would be so difficult.

Thanks for you thoughts, fever

Edit by tye to replace PRE around long lines with CODE

Replies are listed 'Best First'.
Re: Serializing CODE References
by gellyfish (Monsignor) on Feb 06, 2002 at 12:35 UTC

    However, I don’t yet see why generating a semantics for normal CODE refs would be so difficult.

    It's probably easier to start from the other side. With the things that Storable can handle such as, say, a HASH or ARRAY reference it is simple to dereference those things in order to determine the actual value of this things - this can be of varying degrees of difficulty depending on how nested the structured might be, but it is simple to see that given a HASH reference in $foo we can determine the structure of that object and obtain the values of the data therein - this can then be easily represented in serialization in such a way that the same data structure can be recreated on deserialization.

    However, given a CODE reference the action of dereferencing does not give us information that would allow us to recreate the original subroutine: it performs the action that the subroutine was designed to do - this clearly cannot be represented in some datastructure by Storable.

    Update: That said you might be interested to see This post in p5p

    /J\

Re: Serializing CODE References
by dreadpiratepeter (Priest) on Feb 06, 2002 at 15:04 UTC
    You've reached the same conclusion I came to with the same problem. I had to change my event system in my game Tapestry, when I realized that you can't store coderefs.
    But, I'm wondering about something. Are you building the code on the fly? If these jobs are already defined and you just want to store them for easy retrieval couldn't you just make a class with the jobs as methods? then just store the method name in the database, pull it into a variable and call it with Job->$var($args). In fact you could encapsulate the whole process into the object. the constructor retrieves the record from the db and stores the methodname and whatever else is stored, then a run method that calls the appropriate method. i.e.:
    Job->new(id=>3434)->run();

    Of course if the jobs are built on the fly then you are better off storing the subs.

    -pete
    Entropy is not what is used to be.