On 6/18/06, Daniel Berger <djberg96 at gmail.com> wrote:
> Thoughts?
Dan,
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
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.
The second suggestions sounds good, but is far from where I could
understand the impact of implementing that.
I was looking at ruby source (signal.c) and scratching the surface,
IN_MAIN_CONTEXT (which is alias for rb_w32_main_context) offered,
based on conjectures from Nobuyoshi Nakada, could offer some context
switch for the rub interpreter, but couldn't solve if the interpreter
is already running.
I could suggest this:
In Service_Ctrl, set the service status so service_main get the update
and could exit from it. and wait for event "ExitedFromServiceMain".
in the daemon_mainloop, after exiting rb_funcall "service_main",
signal the ExitedFromServiceMain so Service_Ctrl could call the
EventHash and don't trash the ruby interpreter. (Here we could
implemented as IN_MAIN_CONTEXT as a safe-net).
Then signal the EventStop and set the service status as STOPPED.
Hope the "workflow" sounds good, for me it does (but don't have time
to hack it currently now).
Regards,
--
Luis Lavena
Multimedia systems
-
Leaders are made, they are not born. They are made by hard effort,
which is the price which all of us must pay to achieve any goal that
is worthwhile.
Vince Lombardi
>> ---------- Forwarded message ----------
> From: "Patrick Hurley" <phurley at gmail.com>
> To: "Daniel Berger" <djberg96 at gmail.com>
> Date: Sun, 18 Jun 2006 12:46:01 -0400
> Subject: Ruby Win32-Service
> First off I just want to pass on a big thank you, the wonderful win32
> packages 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 you input on how to proceed. I see two options:
>> 1. Only send windows events from Service_Ctrl, and set status flags.
> On calls to status, I could actually call service_stop,
> service_paramchange, etc... This bypasses threading, but trades it for
> a cooperative multi-tasking setup.
>> 2. (Which I prefer, but have never done before). In the extension
> create a ruby thread (green, not OS) which waits on a call back queue)
> and then have Service_Ctrl maintain that queue. This would ensure that
> the Ruby interpreter only runs in one thread - but does involve mixing
> in ruby threading.
>> 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.
>> Thanks again for all your work
> Patrick Hurley
>>>> _______________________________________________
> win32utils-devel mailing list
>win32utils-devel at rubyforge.org>http://rubyforge.org/mailman/listinfo/win32utils-devel>>