01-06-21 22.42, skrev [EMAIL PROTECTED] p� [EMAIL PROTECTED] f�ljande:
> 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
>
Couple of things
This is one thing I see being implmented using hooks first, and if it works
well implment it in the core if it is needed for the speed.
Second, I agree we need a good standard logging interface, I just don't see
this as a good solution.
For the child stuff, why not make it possible for parent-child relationships
to move across the boundieres of a kernel?
Maybe it is time to face the challange and integrate IKC more in the kernel?
Artur
