Actually, any old global variable will do. The whole point
of POE is that its threadless, so there are no concurrency
issues.
So before you start your TCP server, just declare your
resource queue:
our $resource_queue = My::Resource::Queue->new();
And within the states of your POE session, use the
$resource_queue global. As long as your critical sections
are all within the same state, everything should be fine.
-Mathieu
--- [EMAIL PROTECTED] wrote:
> I have written a TCP server using
> POE::Component::Server::TCP. It seems
> to work OK and I've successfully made it into a daemon.
>
> But I'm stumped on my next step. The reason for this
> server is to manage
> the requests which are being received, releasing them in
> a limited and
> orderly fashion. I've designed the fundamental queue
> which will implement
> this, and have designed its methods, but I don't know how
> to implement it
> within the POE context. Obviously the queue must be
> unique, and I'm
> having trouble understanding just how to have all the
> events and sessions
> access this same unique data.
>
> I've had 3 thoughts, but would appreciate comments on
> which is likely to
> be the best route to follow, and perhaps some tips on how
> to implement it.
>
> 1) use $kernel to point to some area of memory which is
> available to every
> event. This memory would then contain the queue
> (actually a set of lists
> which will be continually changing in size). In an
> in-line program a
> single, static hash reference would be sufficient as a
> pointer, but I'm
> not clear on a) how to create such a pointer in $kernel
> (which is an
> ARRAY, not a HASH), or whether such data (in this case
> the reference)
> continues to be valid in all sessions and events once
> things are up and
> running.
>
> 2) create a new session, different from the ones created
> by
> POE::Component::Server::TCP; this session would have to
> be persistent in
> its own right, and its events would have to be able to
> access the
> persistent session's unique heap (where I'd store the
> queue data). The
> events would be different from those of the TCP listening
> wheel, but
> presumably wouldn't clash. My understanding is that the
> persistence is
> ensured by the alias. It still seems to me that the
> session's code might
> have to branch for its different queue-management tasks
> rather than using
> events for them.
>
> 3) create a package (object) for the queue and
> instantiate it before
> starting POE. The documentation that I've been able to
> find so far hints
> that this may be the way to go, but I can see set-up
> order will be
> important. I'm not clear on when to substantiate the
> object. I'm also
> not clear as to whether the queue data should be instance
> properties or
> class properties. Right now, my outline set-up is:
>
> #!/usr/bin/perl
> daemonize();
> use POE qw ( Component::Server::TCP );
> POE::Component::Server::TCP->new ( ... );
> POE::Kernel->run();
> exit 0;
> sub daemonize { # abreviated here
> my $pid = fork;
> exit if $pid;
> return;
> }
> sub inline_code_event { }
> 1;
>
> Please excuse my na�vit� -- this is my initial project
> with POE, or indeed
> any event-driven package. Thanks in advance for any
> help.
>
> Regards, Sam Carmalt
>
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/
