Home > Archive > PERL POE > June 2005 > Avoiding runtime Session collision
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 |
Avoiding runtime Session collision
|
|
| Rodney Rindels 2005-06-09, 4:00 am |
| I'm sure this is just my brain not properly doing a literal join. But
I'm  about how to properly ask the kernel what state a session
is in,
ie.
Does a Session Exist?
If so What state is the Session in?
Avoiding shutdown until a Session is in state x or y ?
Currently I am using sigtraps and handlers to shutdown the kernel, but
It would be nice to extend that logic out if any of the Sessions I
define are not in a "waiting" state, or don't have any wheels attached.
From what I've assembled thusfar, I'm guessing I'll have to alias all
my sessions so I can know who to ask the kernel about.
Basically every minute I have to fire an event that initiaties other
sessions if those sessions are supposed to fire at that time of day. I'm
assuming I'll have to keep some runtime information in a global about
who fired and when as I don't see a shared kernel area for this type of
data. In short I can never have two sessions of the same type running at
the same time and have to avoid runtime collisions, as well as some of
our customers only allow a single connection per day.
A design concern I have is whether I'm going to have to keep my sessions
around long term because of tracking their own behaviors as opposed as
to like a shared kernel $_[HEAP] that could do that for me somehow....
Last question about _start. I notice that when you define a session, its
_start runs immediately, is there a way to initiate a Session at
daemonize time and not actually have it fire until it _start gets
explicitly called.
Rod
| |
| Lance Braswell 2005-06-09, 4:00 am |
|
Rodney Rindels <rrindels@spinn.net> wrote on 05/02/2005 04:43:23 PM:
> I'm sure this is just my brain not properly doing a literal join. But
> I'm about how to properly ask the kernel what state a session
> is in,
> ie.
>
> Does a Session Exist?
> If so What state is the Session in?
> Avoiding shutdown until a Session is in state x or y ?
> Currently I am using sigtraps and handlers to shutdown the kernel, but
> It would be nice to extend that logic out if any of the Sessions I
> define are not in a "waiting" state, or don't have any wheels attached.
>
Handle all your signals and set a global $shutdown in the signal handlers.
Then have your sessions periodically check $shutdown and act appropriately.
> From what I've assembled thusfar, I'm guessing I'll have to alias all
> my sessions so I can know who to ask the kernel about.
>
> Basically every minute I have to fire an event that initiaties other
> sessions if those sessions are supposed to fire at that time of day. I'm
> assuming I'll have to keep some runtime information in a global about
> who fired and when as I don't see a shared kernel area for this type of
> data. In short I can never have two sessions of the same type running at
> the same time and have to avoid runtime collisions, as well as some of
> our customers only allow a single connection per day.
I'm not sure if I understand completely. But what is the session doing? I
guess you could:
my $session = $kernel->alias_resolve("mysession") || &start_mysession; #
but...
I guess I'm wondering if you are having seperate sessions be psuedo events
when instead you might want to have a session that can accept postings from
your scheduler? In other words why the ambiguity about whether or not a
session is active? Need more info here.
>
> A design concern I have is whether I'm going to have to keep my sessions
> around long term because of tracking their own behaviors as opposed as
> to like a shared kernel $_[HEAP] that could do that for me somehow....
>
I always think of any data structure outside of the event definitions (i.e.
globals) as being something like the heap of the kernel? I don't think
there is anything wrong with this if that's your concern.
> Last question about _start. I notice that when you define a session, its
> _start runs immediately, is there a way to initiate a Session at
> daemonize time and not actually have it fire until it _start gets
> explicitly called.
>
Have your session's _start call something like
$kernel->yield('daemon_init') and then define a daemon_init handler. I
think that will run the first chance it gets after the kernel has started.
Then put everything you want in that handler.
> Rod
>
|
|
|
|
|