I'm looking for a generalized interface / pattern to the following problem:
When a remote kernel disconnects, it is frequently necessary to clear up
resources or data that the remote kernel used. Examples would be
unsubscribing or removing locks. This also applies to when sessions in
the local kernel are GCed.
The easy way to implement this is to get remote sessions to tell local
sessions who they are an then monitor for unregister on those kernels.
This fails for 3 reasons: 1- won't work with locally sessions, 2-
requires the remote session not to lie, 3- clutters up the event
interfaces.
Other solution would be SENDER (IKC create thunking sessions, so that
SENDER is temporarily valid). How about something like :
Monitors are set up in the following way :
$kernel->monitor($session, $monitors);
$session can be a reference ($_[SENDER]), alias or even IKC specifier (if
you subscribe to a remote session).
$monitors is a hashrefs, keyed on monitor trigger, values being either an
monitor event name or an arrayref, first value being the monitor event,
others being ARG1..ARGN in the params to the monitor event.
Monitor triggers are one of :
on_stop (when a session is GCed)
on_error (wrap event calls in eval {}, pass $@ to monitor event)
on_oops (non-fatal, but annoying things like posting to non-existant
sessions/events)
on_log (generalized logging mechanism)
on_child (child session created... useful for debuging)
on_post (called when an event posts/calls other events... useful for
debugging and other things I REALLY NEED)
Monitor events are called with ARG0 being a hashref containing some
"interesting" information, like name/alias/specifier of session that
provoked the trigger, error messages, log messages, previous and next event
names...
Examples :
$kernel->monitor("poe://Remote/session", {on_stop=>['game_over',
$something],
on_child=>'new_child'});
When Remote/session is GCed, or when Remote disconnects, 'game_over' is
called with the following params :
ARG0=>{session=>"poe://Remote/session",
trigger=>"on_stop",
},
ARG1=>$something;
When Remote/session creates a child session:
ARGO=>{session=>"poe://Remote/session",
trigger=>"on_child",
parent=>"poe://host-123451235afed/42",
child=>"poe://host-123451235afed/104"
}
host-1234512345afed is remote's kernel ID,
42 and 104 are session IDs
(Maybe this is a bad example?)
Uses :
$kernel->monitor('some_session'=>{on_error=>'some_error'});
When an error occurs in 'some_session', 'some_error' is called with:
ARG0=>{session=>'some_session',
trigger=>'on_error',
state=>'this_state_has_an_error',
line=>42,
file=>103,
error=>$@}
on_log is very similar:
$kernel->monitor('some_session'=>{on_log=>'logger', $interest, $ing});
# ... in an event w/in some_session :
$kernel->log($anything_goes);
Then 'logger' is called with:
ARG0=>{session=>'some_session',
state=>'an event',
list=>24,
file=>1040,
message=>$anything_goes
},
ARG1=>$interest,
ARG2=>$ing,
This will be painful for IKC: thunking sessions are temporary affaires, so
the 'on_stop' monitors would have to be keyed on remote kernel disconnects.
And, we will have to tell remote kernel to propagate any monitors back to
the local kernel....
Can anyone see obvious problems with this solution? Rocco, will this be
far to painful/innefficient to implement? Anyone have other ideas for
triggers?
-Philip
