On Thu, Jan 02, 2003 at 02:42:52PM -0600, Garrett Goebel wrote:
> From: Rocco Caputo [mailto:[EMAIL PROTECTED]]
> > On Thu, Dec 12, 2002 at 05:52:17PM -0600, Garrett Goebel wrote:
> > >
> > > Shouldn't ->yield not just enqueue an event, but also do a
> > > timeslice before returning? I.e., actually yield?
> >
> > No, it's intent is just to enqueue the event. It's very poorly named
> > in that respect, and there have been motions to rename it.
> >
> > http://poe.perl.org/?POE_RFCs/Rename_yield
>
> After reading the s/yield/post/ and ->call implication pages... I was left
> wondering what's wrong with allowing one session to ->post or ->call into
> another session? You mentioned ->call was explicitly redesigned to prevent
> inter-session calling... but not why.
That's incorrect. The call() method still works between sessions that
are in the same process.
I'm considering deprecating inter-session call() because it gets in
the way of networked events. In the nebulous future I would like
sessions to interoperate across process and network boundaries as
easily as they do within a local process.
Inter-session call() is a "very hard" problem, requiring either
threads or synchronous RPC. Threads themselves have proven to be a
"very hard" problem to solve correctly. Synchronous RPC is just plain
bad because it pauses the entire program until call() returns.
> > > If I modify yield by pasting in a $self->run_one_timeslice
> > > before returning, I get the output I expected... but then
> > > POE crashes
> [...]
> >
> > Calling run_one_timeslice() won't guarantee that the "a" event will be
> > handled. The timeslice that gets run might be in some other session,
> > for example.
>
> It would in my contrived example, because there was only the one session...
> but yes, I get what you're after. No garrauntees on what gets the
> time_slice. There would be an end-user expectation that a $kernel->yield
> would timeslice between all sessions, and that $session->yield would be
> local to the $session.
As tidy as the $session->post() and $session->call() syntax is, I
worry that it will interfere with distributed events. The syntax
assumes that a remote $session is in the local process.
Holding extra reference to sessions is also a generally bad thing. It
interferes with session destruction, which in turn prevents things in
HEAPs from being destroyed in timely ways.
> > From the standpoint of yield("event"), it may be more proper for it to
> > call run_one_timeslice() until "event" is dispatched.
> >
> > The combination of post("event") and yield("event") makes this tricky.
> > What if "event" was already in the queue before yield("event") was
> > called? Should we guarantee that the "event" in the yield() call is
> > the one that gets dispatched? In that case, multiple "event" events
> > would be dispatched before yield() returned.
>
> I won't even address ->yield('event') because I'd agree with the people who
> want to replace the current yield with some form of ->post, in favour of a
> parameterless ->yield which yields a timeslice and nothing else.
The current yield() has no parameterless semantics. It's possible to
add something when yield() has no parameters, but I think it would be
better to expose run_one_timeslice() through a separate method.
> > > Is the "-><-a" result more desirable than "->a<-"? And if
> > > you don't beat me to it, would you accept a patch that
> > > resulted in "->a<-"? That is, if I _can_ figure out how
> > > to make it work?
> >
> > I would, but only as part of a long, drawn-out deprecation of the
> > current yield() semantics. We would also need a tidy replacement
> > function for yield(), for the people who like its enqueue-only
> > behavior.
>
> Okay... time permitting I'll see what I can do ;)
Thank you. Please keep in mind inter-process events when working on
this, though. The yield() function is already a nasty mess to undo,
and whatever undoes it should not itself require undoing later.
-- Rocco Caputo - [EMAIL PROTECTED] - http://poe.perl.org/
