OK, I have done some further research and testing. The testing outlined below was all completed with version 20110117 (I have tried numerous times to get the latest version installed on my machine here, however we use ActiveState Perl at work and the only c++ compiler I have access to is through VS Express 2013, which hobbles my ability to compile the module, due to missing libraries - I'll try to get some time to try at home, where I have Strawberry). In addition, the testing was done with both the deprecated running callback and the new(er) timer callback, with the same results in both cases. Wherever I refer to the running callback, I do in fact mean both.
Bug 64717 shows that obtaining the status of the service resets the timer in Win32::Daemon. This was identified in v20101014 and my testing shows that it still exists in v20110117. However, this did give me a couple of ideas:
With this in mind, I tried having the running callback reset the timer every time it is called through use of CallbackTimer. This was ineffective, leading me to believe that whilst the service is still responsive to commands sent by the SCM, there is some interaction happening between the two installed services, causing one of the services to end up having its timer blocked (or potentially indefinitely resetting at a rate faster than the running callback was being called).
Shifting the running callback into a separate thread that performs its own timing and removing the registration is the final piece of testing I have started now. I'll report back on how that performs, though I do think it will work.
UPDATE: As expected, removing the running callback and shifting this control out to a separate thread is working correctly.
In reply to Re: Running callback stops working in Win32::Daemon
by SimonPratt
in thread Running callback stops working in Win32::Daemon
by SimonPratt
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |