On Tue, Feb 10, 2004 at 09:00:01PM -0800, Scott wrote:Only two, relatively minor things.
Rocco Caputo wrote:
Thats only reason #1 I dont support inter-session calling.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.
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.
