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.


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



Reply via email to