On Wed, Feb 11, 2004 at 07:24:58PM -0800, Scott wrote: > Rocco Caputo wrote: > > > >4. The Session->call() syntax, whether it's call() or invoke() or do() > >or something else, does not prohibit inter-session call() anyway. It > >does, however, imply that inter-process call() is not available, since > >you can't refer to the remote session by a registered name. That seems > >more limiting than the current scheme. > > > > > Well, while the semantics of the method may not, the error checking of > it does. That is, my implementation of this method has error checking > to ensure you do not call Session->call() on an object that is not the > currently active session. That solves that problem. Fact being, if we > let them call it on an inactive session, we are going to then end up > with the same problems that Kernel->call() has. If we simply assume > they aren't, we're going to really end up with a headache....ah, but, if > we just error when they do, they cannot...atleast not without extra work > and no real gain. > > >My previous questions stand; there seem to be design options where > >performance is improved without compromising POE's flexibility. > > > > > One is to simply add Session->invoke() and Session->yield(), and call it > a day. Another is to cat /dev/null > the_patch_set, and we probably > have a few more which have not come up yet. :)
In the larger thread I asked whether there couldn't be a Kernel->call() variant that, like yield(), called the current session. It would immediately route the call to $kr_active_session->_invoke_state(), just as Session->invoke() would. There would be no way to specify a remote session, so there is no implication that cross-session calling should be possible with this unnamed method. Looking into the code, one won't find a curious, arbitrary looking C<croak unless $source == $session> test. We avoid hard-to-justify questions like "Why can Kernel->call() do this, but Session->invoke() can't?" The Kernel method would probably be a few microseconds faster than Session->invoke(). For one, it doesn't need the croak test. We seem to have lost sight of the quick optimization of Kernel->call(). It speeds up all wheels immediately---even third-party ones---without adverse side effects. I think that patch should go in regardless of the other decisions. -- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
