win32utils devel - Jun 2006 - Win32-Service and threading

First off I just want to pass on a big thank you to everyone who has
worked on the win32 packages, they have helped me numerous times. But
(of course you knew it had
to be coming :-)...

I have just started doing some work with win32-service -- I was
creating a wrapper around it and daemon.rb, so I could write one body
of code that depending upon platform would provide a reasonable
interface for both windows and Unix platforms. During my testing I
noticed some odd behavior in my test program. Having written a couple
win32 services before I suspected some threading issues, so I did some
digging first just in Ruby using DL, I created a call to
GetCurrentThreadID and in logging I displayed the Current TID -- and
we are switching system threads in the ruby interpreter.

Looking at service.c, I see you are using RegisterServiceCtrlHandler,
there is no guarantee that it will be called from the main thread
(matter of fact it generally won''t). In Service_Ctrl, you make an
rb_funcall using the call back hash, which then calls back into the
interpreter while the main thread is still running under mainloop.

My side effect was some scrambled ruby file handles and some pipe
closed on stopping errors. I would be happy to give back and fix this
issue, but wanted your input on how to proceed.

I have written a few extensions (primarily wrapping in house C/C++
libraries), but have never used ruby threads explicitly in an
extension previously. What I am considering is to create a ruby thread
and have it politely wait for messages in a queue. In Service_Ctrl,
just place entries in the queue. When a message arrives in the queue
have it make the call back (from the Ruby "green" thread).

If you think I am off my rocker and completely misunderstand the
problem, sorry for wasting your time :-); however, if you think I
understand the issue and would like me to take a stab at a patch,
please let me know if my approach sounds reasonable.

Thanks again for all your work
Patrick Hurley

On Jun 18, 2006 10:18 AM, Patrick Hurley <phurley at gmail.com>
wrote:
> First off I just want to pass on a big thank you to everyone who has
> worked on the win32 packages, they have helped me numerous times. But
> (of course you knew it had
> to be coming :-)...
>
> I have just started doing some work with win32-service -- I was
> creating a wrapper around it and daemon.rb, so I could write one body
> of code that depending upon platform would provide a reasonable
> interface for both windows and Unix platforms. During my testing I
> noticed some odd behavior in my test program. Having written a couple
> win32 services before I suspected some threading issues, so I did some
> digging first just in Ruby using DL, I created a call to
> GetCurrentThreadID and in logging I displayed the Current TID -- and
> we are switching system threads in the ruby interpreter.
>
> Looking at service.c, I see you are using RegisterServiceCtrlHandler,
> there is no guarantee that it will be called from the main thread
> (matter of fact it generally won''t). In Service_Ctrl, you make an
> rb_funcall using the call back hash, which then calls back into the
> interpreter while the main thread is still running under mainloop.
>
> My side effect was some scrambled ruby file handles and some pipe
> closed on stopping errors. I would be happy to give back and fix this
> issue, but wanted your input on how to proceed.
>
> I have written a few extensions (primarily wrapping in house C/C++
> libraries), but have never used ruby threads explicitly in an
> extension previously. What I am considering is to create a ruby thread
> and have it politely wait for messages in a queue. In Service_Ctrl,
> just place entries in the queue. When a message arrives in the queue
> have it make the call back (from the Ruby "green" thread).
>
> If you think I am off my rocker and completely misunderstand the
> problem, sorry for wasting your time :-); however, if you think I
> understand the issue and would like me to take a stab at a patch,
> please let me know if my approach sounds reasonable.
I guess we need to revisit this now that 0.6.0 is out. Note that I
plan on rewriting the Daemon class in pure Ruby, too, now that we have
callback support.

Thoughts anyone?

Regards,

Dan