Rocco Caputo wrote:
On Tue, Feb 10, 2004 at 09:00:01PM -0800, Scott wrote:Only two, relatively minor things.
Rocco Caputo wrote:
I'm glad you don't support inter-session calling. You really can't do that without at least setting POE::Kernel's notion of the active session. Otherwise a callee's alarms (and other resources) will be associated with the caller session. That's obviously wrong.
Thats only reason #1 I dont support inter-session calling.
Reason #2 is that I dont even agree call() should be performed inter-session.
[lots of good stuff removed; go back and read it]
And that was the reason I didn't understand why Kernel->call() was faced with so much overhead, of course that is until I realized, it really shouldn't be using _dispatch_event() but it had to, because inter-session calling was permitted. So garbage collection routines and etc were absolutely neccesary. In fact, there isn't much that Kernel->call() does that isn't neccesary aside from a few bitwise operations to determine the current type of event and the neccesary course of action. But much of the overhead of Kernel->call() was easily disposable by disallowing inter-session calls.
Because a serious API change, such as changing the arguements to an existing method or subroutine (for instance, removing the session arguement from Kernel->call()) is difficult to accomidate, I was greatly in favor of the RFC for Revising call.
Unfortunately, the nature of ->call() makes me think it should in fact
be a Kernel method, however that kernel method already exists and is
flawed for the above noted reasons. And this is the rational for
adding a call() method to POE::Session.
Hmm... is there anything stopping you from patching POE::Kernel::call()
to check the resolved destination session against the caller session,
and bypassing _dispatch_event() if they're the same?
First being that I wanted to deprecate the interface for Kernel->call(), ommiting the session parameter as it should be unneccesary.
Second being I was following the revision pattern noted in the wiki.
That suggestion would work perfectly fine as an optimization, but I think the call() method needs revised entirely.
Personally, I look at POE's Sessions in light of Knuth's co-routines.
Since we aren't coding in assembler, we cant actually implement Knuth's
co-routines but Sessions are practically the same thing (Only on a larger scale).
call() exists to avoid race conditions, to get things NOW. I don't think call
should be done inter-session, just as one shouldn't delve into the contents
of an external object. Thats what the public interfaces are for. Also, in
light of the co-routines, inter-session communication should be done via
post(), in order to return processing to the system core, so it can delegate
the next event appropriately.
- Scott.
(Trying anxiously to being a discussion on the mailing list... ;))
Here too. Thanks for reposting it.
Ooops, I forgot to attach the POE::Kernel->call() patch.
- Scott
--- poe/lib/POE/Kernel.pm 2004-02-11 00:28:28.000000000 -0800
+++ poe.optimized.call/lib/POE/Kernel.pm 2004-02-10 23:50:17.000000000 -0800
@@ -1449,6 +1449,8 @@
my $return_value;
if (wantarray) {
$return_value = [
+ $session eq $kr_active_session ?
+ $session->_invoke_state($session, $event_name, [EMAIL PROTECTED], (caller)[1,2]) :
$self->_dispatch_event(
$session, $kr_active_session,
$event_name, ET_CALL, [EMAIL PROTECTED],
@@ -1457,10 +1459,13 @@
];
}
else {
- $return_value = $self->_dispatch_event(
- $session, $kr_active_session,
- $event_name, ET_CALL, [EMAIL PROTECTED],
- (caller)[1,2], time(), -__LINE__
+ $return_value =
+ $session eq $kr_active_session ?
+ $session->_invoke_state($session, $event_name, [EMAIL PROTECTED], (caller)[1,2]) :
+ $self->_dispatch_event(
+ $session, $kr_active_session,
+ $event_name, ET_CALL, [EMAIL PROTECTED],
+ (caller)[1,2], time(), -__LINE__
);
}
