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
Thanks I missed that...
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.
> > 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.
> 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.
> > 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 ;)
--
Garrett Goebel
IS Development Specialist
ScriptPro Direct: 913.403.5261
5828 Reeds Road Main: 913.384.1008
Mission, KS 66202 Fax: 913.384.2180
www.scriptpro.com [EMAIL PROTECTED]
