I've found my issue with threads and Win32::Daemon is related to threads::shared objects losing their tie after StartService is called;
see Odd threads::shared behavior within a Win32::Daemon app for details.
You may find that encapsulating all the Win32::Daemon stuff within
its own thread may limit the overall impact of the issue, tho communicating
stop/pause/resume events between the container and the rest of the app
becomes problematic when you can't use threads::shared structures
8^{. | [reply] [Watch: Dir/Any] |
C# is somewhat Perlish. (Well, I say that for any language that has a foreach loop.)
I've written Windows Services in C# before and it's rather straightforward. However, if you plan to write an installer for .NET Windows Services, that's another story. You have to reverse engineer working MSI's with Orca to see what the Visual Studio setup project is doing if you are building your project outside of Visual Studio. (Undocumented stuff, of course.)
Also there's a bug in v1.1 of .NET which causes deadlock when loading a DLL with .NET and native code. One too many entry points for the load libary call and your program just locks up. Nice... How the hell did they decide to ship .NET with that bug?
| [reply] [Watch: Dir/Any] |
Er, I'm not certain what C#/.NET/VS have to do w/ this particular issue ? If you check my update to Odd threads::shared behavior within a Win32::Daemon app, you'll see I have managed to get
everything working, tho wo/ really understanding why my minor change fixes the problem. Thus far I've gotten 28 threads up and running as a Win32 service, and expect to start testing 50+ on a beefier server in the next few days.
The only remaining area of concern I have is the autorecovery issue, which I already know how to fix (using plain old C/C++ and the new API I linked in my update in the OP), but don't have time at the moment.
Admittedly, MSFT has once again made this process is a PITA,
but once I figured it all out, it's not too bad. I spose I should writeup a little Meditation or Cool Uses article on the process.
| [reply] [Watch: Dir/Any] |