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
>
