in reply to Re: replace object methods at runtime
in thread replace object methods at runtime

Sure ,

A little context first. I am writing SNMP Trap handling framework. I have started with Net-SNMP's snmptrapd with embedded perl interpreter and I have written the first version of the framework and some heavy duty trap handlers for it. Then I realized that it leaks like hell - 1G RAM for 2-3 hours. And it is not my fault because it leaks with empty handlers a lot of memory too

The next step was to write my own trap-daemon based on SNMP_Session.pm and BER.pm. It take me one morning the daemon and the afternoon to port and tune the existing trap-handlers.

So now the architecture is quite configurable and pluggable but is modeled upon the initial implementation. It consists of one central process that at the start loads the configured modules and then fires the appropriate handlers for the received traps.

All the trap handlers inherit from one class "Trap" that makes simple decoding of the trap and manages the live-cycle of the handler. I have decided to spawn new process for each handler and to communicate via pipes with it. In this way I could get lazy forking and initialization of the handlers and to manage situations like the death of some workers. So for now I have code that goes like this:

sub new { my $type = shift; my $class = ref $type || $type; my $self = { trap => [], cfg => shift }; bless $self, $class; return sub { $self->receiver(@_) }; } sub _default_receiver { my ($self,$vars) = @_; my $fd; if ( my $pid = open($fd, "|-" )){ # Fork $fd->autoflush(); $__PACKAGE__::to_die{$pid}=$self; $self->{receiver} = sub { # Replace receiver in parent my ($self1,$v)= @_; store_fd($v,$fd); # Send }; $self->receiver($vars); # The first trap }else{ $self->init(); # Init child here while ( my $v = fd_retrieve( \*STDIN ) ) { my $r = {}; ... do some work here .... push @{$self->{trap}},$r; $self->handler(); } $self->destroy(); } }

The constructor return a closure that will be run for each received trap. The idea of the "dynamic method rewriting" is that the "receiver"(_default_receiver) will fork new process only the first time and then replace itself with "receiver" (the closure) that just feeds the created worker with data. If this process dies we deleting the "receiver", so the next time it will call the _default_receiver and will fork new process. (SIGCHLD handler not shown in the code).

This version uses the AUTOLOAD approach suggested by salva. I am not coping the code of AUOTLOAD sub that looks quite like the code he suggested

I am open to all kinds of suggestions and advises.

Thanks in advance

Replies are listed 'Best First'.
Re^3: replace object methods at runtime
by BrowserUk (Patriarch) on Jun 25, 2008 at 13:41 UTC
    Sure ,

    Thank you for indulging me. I've seen this kind of facility requested (or described in other languages), but I've never really seen a non-hypothetical use-case for it. And I'm always more interested in real use cases than hypothetical ones.

    That said, without fully understanding the architecture you are describing, it sounds like a complex way of coding a simple boolean condition? Essentially:

    sub method { my( $self, @args ) = @_; ... if( $self->_pipeExistsAndIsGood ) { ## communicate with pipe } else { ## $self->_forkAndStorePipe(); } }

    I can see that 'dynamic method rewriting' is a way to avoid a boolean test, which might provide a small efficiency gain, but trading that for the complexity and 'action at a distance' involved runtime determination of the code behind a method, along with parent & child time forked instances, just seems like a recipe for complex and difficult to trace bugs and failures.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Yes, the "boolean test" method is more simple and maintainable. As a performance it is equal or better to the approach with wrappers/AUTOLOAD because you always must check some condition in the wrapper.

      I see that if we have symtables per instance this will hurt the performance of all objects and the gain in flexibility is minimal. The suggested re-blessing method seems more general and could do the same without penalty for other objects.

      Thanks
      luben

Re^3: replace object methods at runtime
by salva (Canon) on Jun 25, 2008 at 11:12 UTC
    Maybe, you can use Class::StateMachine. It lets you define several implementations for the same method and then select which one to use based on an internal "state" property.

    Internally, it uses a reblessing approach very similar to the one exposed by DrHyde below.