On Tue, Feb 10, 2004 at 04:23:44PM -0800, Scott wrote:Thats only reason #1 I dont support inter-session calling.
However, I just want to know if anyone applied the patch, had problems applying the patch or running the tests afterwards, or any such thing.
I think a $_[SESSION]->call() is a great idea for a number of reasons,
offers an interface to high level event routing for component writers should
they want to do so, offers an optimization for the wheel implementations
(Although the wheel things have been argued to suck for a variety of reasons,
no reason to not make them faster), and a yield-like convienent intra-session
interface for call ($_[SESSION]->call(state => @args) - obviously).
But again, I'm just really itching to know if anyone had any luck with these
patches...c'mon I'm looking for feedback here people.!
I looked in the patch, but I haven't installed it or anything. I'm still waiting for people to get involved with design discussion on the list.
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.
Simply put, my vision of a POE Session is that of a knuth co-routine, heaps and etc
are whats used to create persistency, since a by-definition co-routine is slightly less
than possible in a modern, functional programming language. Our subroutines only
have one entry point, but a session is a composition of subroutines that form a single
persistent entity (which is exactly what a larger-scale co-routine would end up being).
Sometimes it is neccesary to call within our subroutines, because we need to do this
thing NOW, or else face race conditions, etc. But if we're relying on another session
to do something for our session that may cause a race condition, I consider that
a design flaw. Inter-session, events should be posted as to keep the design pattern
of a cooperative environment in tact, that is, quickly return processing to the core so
it can delegate the next step according to priorities it manages for us.
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.
(Trying anxiously to being a discussion on the mailing list... ;))
- Scott
