PERL POE - Shared memory in a non-blocking server

Author

Shared memory in a non-blocking server

scarmalt@iec.ch

2005-06-08, 9:04 pm

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

Mathieu Longtin

2005-06-08, 9:04 pm

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

--- scarmalt@iec.ch 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/

Sponsored Links