Rodney Rindels <[EMAIL PROTECTED]> 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 confused 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
>
