My thought is to have the service start a new thread that handles socket connections and responses while the main thread runs the looping processes. Would it be hard for it to view some main thread variables to obtain status?
No, no problem at all. Just share the variables that you want the status thread to be able to see, and add:
my $sharedVar : shared; .... { lock( $sharedVar ); #do stuff with $sharedVar }
around each access to those shared variables in both pieces of code.
If your going to use a package like IO::Socket::INET to provide the communications within the status thread, require it within that thread rather than useing it at the top of the script.
In essence that is all there is to it.
There are some limitations about what types of variable can be shared--filehandles (hackable) and objects or tied vars (not easily hackable)--but that needn't be a great limitation.
Does anyone have any thoughts on a direction for this task?
From your description so far, using a thread would seem the ideal route to me.
Of course, the devil is in the detail--in this case, the detail of exactly what information you want to share between the threads.
In reply to Re: Thoughts on how to devise a queryable win32 service
by BrowserUk
in thread Thoughts on how to devise a queryable win32 service
by noslenj123
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |