(): 34 wallclock secs (33.82 usr + 0.01
sys = 33.83 CPU) @ 29559.56/s (n=100)
(Old) POE::Kernel-call(): 48 wallclock secs (46.80 usr + 0.35 sys =
47.15 CPU) @ 21208.91/s (n=100)
POE::Session-call(): 22 wallclock secs (21.64 usr + 0.01 sys = 21.65
CPU) @ 46189.38/s (n=100
Scott wrote:
Rocco Caputo wrote:
On Tue, Feb 10, 2004 at 09:00:01PM -0800, Scott wrote:
Rocco Caputo wrote:
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
) @ 29559.56/s (n=100)
(Old) POE::Kernel-call(): 48 wallclock secs (46.80 usr + 0.35 sys =
47.15 CPU) @ 21208.91/s (n=100)
POE::Session-call(): 22 wallclock secs (21.64 usr + 0.01 sys = 21.65
CPU) @ 46189.38/s (n=100)
Attached is the patch that performs this optimization to POE::Kernel
Nicholas Perez wrote:
Okay, I am no POE internal genius, and perhaps I am using call()
inappropriately (inter-session), but I find a lot of convenience in
using a separate Session to hold data that needs to be
synchronized/serialized.
You should be using an object or global structure, or the
Scott wrote:
[...]
If you're really only storing data, you really should use an object OR
package in the ways I mentioned above. Atleast, if you have any
desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of removing
inter-session calling all together.
Nick Williams wrote:
Scott wrote:
[...]
If you're really only storing data, you really should use an object
OR package in the ways I mentioned above. Atleast, if you have any
desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of removing
inter-session
-Language: en-us, en
MIME-Version: 1.0
To: Scott [EMAIL PROTECTED]
Subject: Re: POE::Session-call()
References: [EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED]
[EMAIL PROTECTED] [EMAIL PROTECTED
*nods*
My applications do the exact same thing and absolutely thrive on
intersession calls. No touchie. :) Thanks.
On Wed, 11 Feb 2004, Nick Williams wrote:
I have a fairly complex system that runs various background monitoring
tasks (using Wheel::Run) and also takes in requests from the
Scott wrote:
Nick Williams wrote:
Scott wrote:
[...]
If you're really only storing data, you really should use an object
OR package in the ways I mentioned above. Atleast, if you have any
desire to maintain efficiency.
Now here I must note, that I didn't come up with the idea of
removing
Nick Williams wrote:
Scott wrote:
Nick Williams wrote:
Scott wrote:
[...]
If you're really only storing data, you really should use an object
OR package in the ways I mentioned above. Atleast, if you have any
desire to maintain efficiency.
Now here I must note, that I didn't come up with
Scott wrote:
[...]
I mean this in the nicest way possible, because I honestly can't think
of a nicer way to say it without being unclear of my opinion.
I really don't think that anyone should be so pretentious as to say
you don't need this [feature] to a programming community, doing so
leads
-session calling, and in
addition, it also not an arguement against POE::Session-call(). Just
because you /can/ make everything an event, doesn't neccesarily mean it
should be given or even encouraged that you should make things which
rely on a synchronous state and then shoe-horn them
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
Rocco Caputo wrote:
On Mon, Feb 09, 2004 at 06:02:27PM -0800, Scott wrote:
There was a problem with this patch, which unlikely got noticed due
to the fact that it would not have caused an error until you used the
ReadWrite wheel with a depricated filter object. The test suite does
not
On Tue, Feb 10, 2004 at 04:23:44PM -0800, Scott wrote:
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
On Tue, Feb 10, 2004 at 09:00:01PM -0800, Scott wrote:
Rocco Caputo wrote:
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
Rocco Caputo wrote:
On Tue, Feb 10, 2004 at 09:00:01PM -0800, Scott wrote:
Rocco Caputo wrote:
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
On Mon, Feb 09, 2004 at 06:02:27PM -0800, Scott wrote:
There was a problem with this patch, which unlikely got noticed due
to the fact that it would not have caused an error until you used the
ReadWrite wheel with a depricated filter object. The test suite does
not check this behavior,
Hello POEple.
http://poe.perl.org/?POE_RFCs/Revise_call mentions adding a
POE::Session-call() method, in part of the revision of call. This new
session method is intended to deny cross-session calls, which as a side
effect allows extended optimization of call() bypassing garbage
19 matches
Mail list logo
