Attached is a patch and my service.c if there is any difficulty applying the patch. I did the following: 1. Created a ruby thread (Ruby_Service_Ctrl), that polls against a simple integer value (protected by a critical section). I was worried this would be "expensive"; however, I found the rb_thread_polling method and it seems to work well. 2. When an event occurs in Service_Ctrl it sets the flag value. 3. If Ruby_Service_Ctrl finds an entry in the call back hash it invokes it (in its own thread) and goes back to polling 4. On a SERVICE_CONTROL_STOP the Ruby_Service_Ctrl, processes normally and then begins to exit, but it first waits for all previously spun threads to return. 5. Service_Ctrl on a stop waits for Ruby_Service_Ctrl to indicate that all threads are stopped before stopping the service (it continues to update service status politley). That''s it -- in my tests it works perfectly. If I made any fax paus in my patch creation or summary please let me know. Thanks again pth -------------- next part -------------- A non-text attachment was scrubbed... Name: green_thread.patch Type: application/octet-stream Size: 4627 bytes Desc: not available Url : http://rubyforge.org/pipermail/win32utils-devel/attachments/20060619/8cb30214/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: service.c Type: application/octet-stream Size: 57877 bytes Desc: not available Url : http://rubyforge.org/pipermail/win32utils-devel/attachments/20060619/8cb30214/attachment-0003.obj
This is a second post of this message -- service.c was too big and caused the list to bounce it. Attached is a patch and my service.c.bz2 if there is any difficulty applying the patch. I did the following: 1. Created a ruby thread (Ruby_Service_Ctrl), that polls against a simple integer value (protected by a critical section). I was worried this would be "expensive"; however, I found the rb_thread_polling method and it seems to work well. 2. When an event occurs in Service_Ctrl it sets the flag value. 3. If Ruby_Service_Ctrl finds an entry in the call back hash it invokes it (in its own thread) and goes back to polling 4. On a SERVICE_CONTROL_STOP the Ruby_Service_Ctrl, processes normally and then begins to exit, but it first waits for all previously spun threads to return. 5. Service_Ctrl on a stop waits for Ruby_Service_Ctrl to indicate that all threads are stopped before stopping the service (it continues to update service status politley). That''s it -- in my tests it works perfectly. If I made any fax paus in my patch creation or summary please let me know. Thanks again pth -------------- next part -------------- A non-text attachment was scrubbed... Name: green_thread.patch Type: application/octet-stream Size: 4627 bytes Desc: not available Url : http://rubyforge.org/pipermail/win32utils-devel/attachments/20060619/6dcb340c/attachment-0001.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: service.c.bz2 Type: application/x-bzip2 Size: 9650 bytes Desc: not available Url : http://rubyforge.org/pipermail/win32utils-devel/attachments/20060619/6dcb340c/attachment-0001.bin
Hi, 2006/6/20, Patrick Hurley <phurley at gmail.com>:> Attached is a patch and my service.c if there is any difficulty > applying the patch. I did the following: > > 1. Created a ruby thread (Ruby_Service_Ctrl), that polls against a > simple integer value (protected by a critical section). I was worried > this would be "expensive"; however, I found the rb_thread_polling > method and it seems to work well. > > 2. When an event occurs in Service_Ctrl it sets the flag value. > > 3. If Ruby_Service_Ctrl finds an entry in the call back hash it > invokes it (in its own thread) and goes back to polling > > 4. On a SERVICE_CONTROL_STOP the Ruby_Service_Ctrl, processes normally > and then begins to exit, but it first waits for all previously spun > threads to return. > > 5. Service_Ctrl on a stop waits for Ruby_Service_Ctrl to indicate that > all threads are stopped before stopping the service (it continues to > update service status politley). > > That''s it -- in my tests it works perfectly. If I made any fax paus in > my patch creation or summary please let me know. > > Thanks again > pth >That is a really good pacth! I confirmed the patch works perfectly. Thanks, Park Heesob
Patrick Hurley wrote:> Attached is a patch and my service.c if there is any difficulty > applying the patch. I did the following: > > 1. Created a ruby thread (Ruby_Service_Ctrl), that polls against a > simple integer value (protected by a critical section). I was worried > this would be "expensive"; however, I found the rb_thread_polling > method and it seems to work well. > > 2. When an event occurs in Service_Ctrl it sets the flag value. > > 3. If Ruby_Service_Ctrl finds an entry in the call back hash it > invokes it (in its own thread) and goes back to polling > > 4. On a SERVICE_CONTROL_STOP the Ruby_Service_Ctrl, processes normally > and then begins to exit, but it first waits for all previously spun > threads to return. > > 5. Service_Ctrl on a stop waits for Ruby_Service_Ctrl to indicate that > all threads are stopped before stopping the service (it continues to > update service status politley). > > That''s it -- in my tests it works perfectly. If I made any fax paus in > my patch creation or summary please let me know. > > Thanks again > pth > ------------------------------------------------------------------------ > > _______________________________________________ > win32utils-devel mailing list > win32utils-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-develMany thanks Patrick, we''ll take a look. In the meantime I''m going to release 0.5.1 (tonight). Assuming everything looks good with your patch, I''m going to save it for 0.5.2. Regards, Dan PS - Sorry for the late approval on this message - I was at work.
Heesob Park wrote:> Hi, > > 2006/6/20, Patrick Hurley <phurley at gmail.com>: > >> Attached is a patch and my service.c if there is any difficulty >> applying the patch. I did the following: >> >> 1. Created a ruby thread (Ruby_Service_Ctrl), that polls against a >> simple integer value (protected by a critical section). I was worried >> this would be "expensive"; however, I found the rb_thread_polling >> method and it seems to work well. >> >> 2. When an event occurs in Service_Ctrl it sets the flag value. >> >> 3. If Ruby_Service_Ctrl finds an entry in the call back hash it >> invokes it (in its own thread) and goes back to polling >> >> 4. On a SERVICE_CONTROL_STOP the Ruby_Service_Ctrl, processes normally >> and then begins to exit, but it first waits for all previously spun >> threads to return. >> >> 5. Service_Ctrl on a stop waits for Ruby_Service_Ctrl to indicate that >> all threads are stopped before stopping the service (it continues to >> update service status politley). >> >> That''s it -- in my tests it works perfectly. If I made any fax paus in >> my patch creation or summary please let me know. >> >> Thanks again >> pth >> >> > That is a really good pacth! > I confirmed the patch works perfectly. > > Thanks, > > Park Heesob > _______________________________________________ > win32utils-devel mailing list > win32utils-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-devel > >Cool. The mission of the people on this list, should you choose to accept it, is to try your best to break it. I''d also like to get some feedback from the Mongrel folks (Luis?), since they seem to be one of the major users/stress testers. Regards, Dan
> -----Original Message----- > From: win32utils-devel-bounces at rubyforge.org > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > Patrick Hurley > Sent: Monday, June 19, 2006 10:31 AM > To: Development and ideas for win32utils projects > Subject: [Win32utils-devel] win32-service patch > > > Attached is a patch and my service.c if there is any > difficulty applying the patch. I did the following:<snip> Do you want to rework this in light of Paul Brannan''s suggestion to use TRAP_BEG and TRAP_END or sem_wait? In the meantime I should mention that I''d like to move the Service class (not the Daemon class) over to a pure Ruby solution. Regards, Dan This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.
On 6/20/06, Berger, Daniel <Daniel.Berger at qwest.com> wrote:> > > > -----Original Message----- > > From: win32utils-devel-bounces at rubyforge.org > > [mailto:win32utils-devel-bounces at rubyforge.org] On Behalf Of > > Patrick Hurley > > Sent: Monday, June 19, 2006 10:31 AM > > To: Development and ideas for win32utils projects > > Subject: [Win32utils-devel] win32-service patch > > > > > > Attached is a patch and my service.c if there is any > > difficulty applying the patch. I did the following: > > <snip> > > Do you want to rework this in light of Paul Brannan''s suggestion to use > TRAP_BEG and TRAP_END or sem_wait? > > In the meantime I should mention that I''d like to move the Service class > (not the Daemon class) over to a pure Ruby solution. > > Regards, > > Dan > > > This communication is the property of Qwest and may contain confidential or > privileged information. Unauthorized use of this communication is strictly > prohibited and may be unlawful. If you have received this communication > in error, please immediately notify the sender by reply e-mail and destroy > all copies of the communication and any attachments. > _______________________________________________ > win32utils-devel mailing list > win32utils-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/win32utils-devel >The existing solution works and I do not think (although I would love to find out I am wrong), TRAP_BEG/TRAP_END are magical enough to make this easy. So I would say put it in as soon as it makes sense as it fixes easy to reproduce bugs. If I/we can develop a better solution it can be put in later -- I personally need to do more testing before I trust threaded code using an API that is undocumented (except in the source, which does not look like it does anything more than prevent signals). As for seperating service from daemon -- that makes a lot of sense it is a little confusing as implemented -- at least partially because the docs are describing two completely different types of functionality. pth
On 6/19/06, Patrick Hurley <phurley at gmail.com> wrote:> This is a second post of this message -- service.c was too big and > caused the list to bounce it. Attached is a patch and my service.c.bz2 > if there is any difficulty > applying the patch. I did the following: >[snip]> That''s it -- in my tests it works perfectly. If I made any fax paus in > my patch creation or summary please let me know. >Hello Patrick. The patch sounds and look good, but I cannot build it here. This is the output of building 0.5.0: Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. C:\ruby\bin\ruby -e "puts ''EXPORTS'', ''Init_service''" > service-i386-mswin32.def cl -nologo -MD -Zi -O2b2xg- -G6 -I. -IC:/ruby/lib/ruby/1.8/i386-mswin32 -IC:/ruby/lib/ruby/1.8/i386-mswin32 -I. -DHAVE_ENUMSERVICESSTATUSEX -DHAVE_QUERYSERVICESTATUSEX -c -Tcservice.cservice.c cl -nologo -LD -Feservice.so service.obj msvcrt-ruby18.lib oldnames.lib user32.lib advapi32.lib wsock32.lib -link -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"C:/ruby/lib" -def:service-i386-mswin32.def -implib:service-i386-mswin32.lib -pdb:service-i386-mswin32.pdb Creating library service-i386-mswin32.lib and object service-i386-mswin32.exp And this is with your service.c file replacing the original: Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 Copyright (C) Microsoft Corp 1988-1998. All rights reserved. cl -nologo -MD -Zi -O2b2xg- -G6 -I. -IC:/ruby/lib/ruby/1.8/i386-mswin32-IC:/ruby/lib/ruby/1.8/i386-mswin32 -I. -DHAVE_ENUMSERVICESSTATUSEX -DHAVE_QUERYSERVICESTATUSEX -c -Tcservice.cservice.c cl -nologo -LD -Feservice.so service.obj msvcrt-ruby18.lib oldnames.lib user32.lib advapi32.lib wsock32.lib -link -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"C:/ruby/lib" -def:service-i386-mswin32.def -implib:service-i386-mswin32.lib -pdb:service-i386-mswin32.pdb Creating library service-i386-mswin32.lib and object service-i386-mswin32.exp service.obj : error LNK2019: unresolved external symbol _rb_get_dependencies referenced in function _service_services service.obj : error LNK2019: unresolved external symbol _rb_get_error_control referenced in function _service_services service.obj : error LNK2019: unresolved external symbol _rb_get_start_type referenced in function _service_services service.so : fatal error LNK1120: 3 unresolved externals NMAKE : fatal error U1077: ''cl'' : return code ''0x2'' Stop. What I''m missing? Maybe is because I''m tired, but couldn''t see why this is happening... Thank you for your time, -- 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
Hi, 2006/6/22, Luis Lavena <luislavena at gmail.com>:> On 6/19/06, Patrick Hurley <phurley at gmail.com> wrote: > > This is a second post of this message -- service.c was too big and > > caused the list to bounce it. Attached is a patch and my service.c.bz2 > > if there is any difficulty > > applying the patch. I did the following: > > > [snip] > > That''s it -- in my tests it works perfectly. If I made any fax paus in > > my patch creation or summary please let me know. > > > > Hello Patrick. > > The patch sounds and look good, but I cannot build it here. > > This is the output of building 0.5.0: > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > C:\ruby\bin\ruby -e "puts ''EXPORTS'', ''Init_service''" > > service-i386-mswin32.def > cl -nologo -MD -Zi -O2b2xg- -G6 -I. > -IC:/ruby/lib/ruby/1.8/i386-mswin32 > -IC:/ruby/lib/ruby/1.8/i386-mswin32 -I. -DHAVE_ENUMSERVICESSTATUSEX > -DHAVE_QUERYSERVICESTATUSEX -c -Tcservice.cservice.c > cl -nologo -LD -Feservice.so service.obj msvcrt-ruby18.lib > oldnames.lib user32.lib advapi32.lib wsock32.lib -link > -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"C:/ruby/lib" > -def:service-i386-mswin32.def -implib:service-i386-mswin32.lib > -pdb:service-i386-mswin32.pdb > Creating library service-i386-mswin32.lib and object service-i386-mswin32.exp > > > And this is with your service.c file replacing the original: > Microsoft (R) Program Maintenance Utility Version 6.00.8168.0 > Copyright (C) Microsoft Corp 1988-1998. All rights reserved. > > cl -nologo -MD -Zi -O2b2xg- -G6 -I. > -IC:/ruby/lib/ruby/1.8/i386-mswin32-IC:/ruby/lib/ruby/1.8/i386-mswin32 > -I. -DHAVE_ENUMSERVICESSTATUSEX -DHAVE_QUERYSERVICESTATUSEX -c > -Tcservice.cservice.c > cl -nologo -LD -Feservice.so service.obj msvcrt-ruby18.lib > oldnames.lib user32.lib advapi32.lib wsock32.lib -link > -incremental:no -debug -opt:ref -opt:icf -dll -libpath:"C:/ruby/lib" > -def:service-i386-mswin32.def -implib:service-i386-mswin32.lib > -pdb:service-i386-mswin32.pdb > Creating library service-i386-mswin32.lib and object service-i386-mswin32.exp > > service.obj : error LNK2019: unresolved external symbol > _rb_get_dependencies referenced in function _service_services > service.obj : error LNK2019: unresolved external symbol > _rb_get_error_control referenced in function _service_services > service.obj : error LNK2019: unresolved external symbol > _rb_get_start_type referenced in function _service_services > service.so : fatal error LNK1120: 3 unresolved externals > NMAKE : fatal error U1077: ''cl'' : return code ''0x2'' > Stop. >All above functions are defined at service.h I guess you have incorrect version of service.h. Regards, Park Heesob
On 6/22/06, Heesob Park <phasis at gmail.com> wrote:> Hi, > > 2006/6/22, Luis Lavena <luislavena at gmail.com>: > > On 6/19/06, Patrick Hurley <phurley at gmail.com> wrote: > > > This is a second post of this message -- service.c was too big and > > > caused the list to bounce it. Attached is a patch and my service.c.bz2 > > > if there is any difficulty > > > applying the patch. I did the following: > > > > > [snip] > > > That''s it -- in my tests it works perfectly. If I made any fax paus in > > > my patch creation or summary please let me know. > > > > > > > Hello Patrick. > > > > The patch sounds and look good, but I cannot build it here. > > > > This is the output of building 0.5.0:[snip]> All above functions are defined at service.h > I guess you have incorrect version of service.h.Park, you''re right. I was replacing service.c in the 0.5.0, instead of 0.5.1. I''ll test this with mongrel (for mongrel win32 services) and chck if that solved/helped the problem when mixing ruby/native threads. 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