[Win32utils-devel] [Fwd: Ruby Win32-Service]

Heesob Park phasis at gmail.com
Sun Jun 18 20:41:48 EDT 2006


2006/6/19, Patrick Hurley <phurley at gmail.com>:
> On 6/18/06, Luis Lavena <luislavena at gmail.com> wrote:
> > I faced the same issue of the guy pointed out.
> >
> > Calling the EventHash from other native thread (not the one where ruby
> > interpreter is running) trash everything. Worse is that the
> > interpreter is currently "looping" in service_main
> Exactly, ok so I am not off my rocker :-)
As you know, using native thread is not recommended in the current ruby version.

> > As I understand the idea of Patrick, we could emulate the threading of
> > Service_Ctrl in a green thread, something that will not work quite
> > right without us pulling status in a regular basis.
> Since I am going to use this for work, I can spend some paid time
> tomorrow following up. I went through the C extension docs and it
> looks pretty easy to create a green thread attached to an actual C
> function. So my plan is as follows:
> 1. Create a Win32 Semaphore and mutex, that mirrors a simple list of
> events (e.g. param change, stop, pause, etc).
> 2. In ServiceCtrl when ever a ruby call back is required: I will lock
> the mutex, place an item in the list, increment the semaphor and
> release the mutex.
> 3. In a green thread I will be waiting on the semaphor -- I am not
> sure if this will block ruby's green threads if it does I will have to
> spin against the semaphor and a ruby sleep -- ugly, but very doable.
> 4. When events arrive in the list, I will make the call back into the
> main class -- this will occur in the same system thread, but a
> different "ruby thread".
> The only thing I am unsure of is #3, If a Ruby thread blocks on a
> Win32 object, I think it will hang ruby -- if anyone has any
> experience with this I would love to hear it -- otherwise I may spend
> some time looking through the Ruby source to see if there is an
> internal to allow waiting without the spin.
Although all the above might be possible, it will not work with
SCM(Service Control Manager). Thus you must call
"StartServiceCtrlDispatcher" API to connect with the SCM.
The main problem is "StartServiceCtrlDispatcher" blocks and returns
only when the serivce has terminated.
If you can make StartServiceCtrlDispatcher nonblocking, I guess there
is no problem at all.


Park Heesob

More information about the win32utils-devel mailing list