On Tue, Feb 10, 2004 at 09:00:01PM -0800, Scott wrote: > 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? > (Trying anxiously to being a discussion on the mailing list... ;)) Here too. Thanks for reposting it. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
