Home > Archive > PERL POE > March 2008 > concurrency and Server::TCP
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
concurrency and Server::TCP
|
|
| vidals 2008-02-13, 7:38 pm |
| I have an app that I wrote which is sensitive to being overwhelmed by
POE's multitasking. I couldn't figure out a way to "slow" it down and
run serially, so I set Concurrency = 1 like so:
POE::Component::Server::TCP->new(
Address => ListenAddr,
Port => ListenPort,
#Alias => 'name',
Concurrency => 1, # 1 means run sequentially; default -1?
(infinite)
ClientInput => \&process_input,
If I run it with Concurrency 1, then I see that ClientInput only
accepts input chronologically - one at a time. Where does POE store
the queued requests of ClientInput? There seems to be an implied
buffer somewhere?
--Gil Vidals
| |
| Scott S. McCoy 2008-03-12, 8:10 pm |
| Indeed, POE has an internal queue stored in POE::Kernel backed by
POE::Queue::Array. This queue is an event queue (and is how POE enables
multitasking, really) and is the same queue which all yielded states,
alarms, and IO events pass through.
Similarly, POE::Component::Servier::TCP creates a POE::Wheel::ReadWrite
which uses a POE::Filter which also has a buffer of it's own, it acts
(thanks to the ReadWrite wheel) on I/O events which happen in that
socket, collecting the contingent chunks of information until it has a
suitable segment to consider an "event". If using POE::Filter::Line
(IIRC, that's the name of it, and the default) then this is when you get
a newline character in the stream. If 538 bytes become available, for
instance, and the 236th byte is a newline, it will dispatch an event
with bytes 0-235 to the ClientInput event, and keep the rest in it's
buffer, waiting for the next newline.
This behavior is all configurable, naturally.
Cheers,
Scott S. McCoy
On Wed, 2008-02-13 at 14:28 -0800, vidals wrote:
> I have an app that I wrote which is sensitive to being overwhelmed by
> POE's multitasking. I couldn't figure out a way to "slow" it down and
> run serially, so I set Concurrency = 1 like so:
>
> POE::Component::Server::TCP->new(
> Address => ListenAddr,
> Port => ListenPort,
> #Alias => 'name',
> Concurrency => 1, # 1 means run sequentially; default -1?
> (infinite)
> ClientInput => \&process_input,
>
> If I run it with Concurrency 1, then I see that ClientInput only
> accepts input chronologically - one at a time. Where does POE store
> the queued requests of ClientInput? There seems to be an implied
> buffer somewhere?
>
> --Gil Vidals
>
| |
| Matt Sickler 2008-03-12, 8:10 pm |
| Also, ClientInput is a callback specific to the POE::Session that handles a
single connection.
POE is a multitasking environment, not a threaded one - so you are going to
only be processing one line of code at a time anyway.
On Wed, Feb 13, 2008 at 5:28 PM, vidals <gvidals@gmail.com> wrote:
> I have an app that I wrote which is sensitive to being overwhelmed by
> POE's multitasking. I couldn't figure out a way to "slow" it down and
> run serially, so I set Concurrency = 1 like so:
>
> POE::Component::Server::TCP->new(
> Address => ListenAddr,
> Port => ListenPort,
> #Alias => 'name',
> Concurrency => 1, # 1 means run sequentially; default -1?
> (infinite)
> ClientInput => \&process_input,
>
> If I run it with Concurrency 1, then I see that ClientInput only
> accepts input chronologically - one at a time. Where does POE store
> the queued requests of ClientInput? There seems to be an implied
> buffer somewhere?
>
> --Gil Vidals
>
>
|
|
|
|
|