[Win32utils-devel] Hooks for win32-service

win32utils-devel at rubyforge.org win32utils-devel at rubyforge.org
Wed Feb 4 10:16:04 EST 2004


> 
>  > I added service control signal hooks in service.c and 
> > daemon_test.c Enjoy and modify code for your taste. My code 
> > may be not suitable for your taste :-)
> 
> Nice!
> 
> Is there any way we can cut this down from a two part process to a one
> part process?  For example, with the current code you would define a
> stop hook like this:
> 
> class Daemon
>    def on_stop
>       File.open('c:\log.txt','a+'){ |f| f.puts "Service stopped" }
>    end
> 
>    def worker
>       evt_hook(CONTROL_STOP) { on_stop }
>       ...
>    end
> end
> 
> Can we alter the API such that there are a series of predefined methods
> that automatically get called for the appropriate signal?  e.g.
> 
> class Daemon
>    # This method would automatically be called when CONTROL_STOP signal
> was received.
>    def on_stop
>       File.open('c:\log.txt','a+'){ |f| f.puts "Service stopped" }
>    end
> 
>    def worker
>       # No need to specify evt_hook
>    end
> end
> 
> In other words, define an "on_stop" method (or whatever we want to call
> it) within the Daemon class that the user can define and is
> automatically called when a CONTROL_STOP signal is received?  The only
> drawback to this that I can see would be a lot of potential no-op calls
> where the user hasn't explicitly defined the method themselves.
> 
> This doesn't concern me though, because the performance impact should be
> minimal, and generally I'm not worried about signal handling performance
> anyway.  If it takes .001 seconds longer to stop or start a service, so
> be it.  I'd rather have the nicer syntax. :)
> 
OK, agreed. KISS!
It is up to you.
I know you can modify it for your taste. :)

> > There was bug in daemon_test.c 
> > "state==SERVICE_RUNNING" should be "state==RUNNING".
> 
> Odd, I could have sworn I changed it.  Thanks for the fix. :)
> 
:)

Regards, 

Park Heesob



--MIME Multi-part separator--



More information about the win32utils-devel mailing list