In my server application there is a pool of threads calling the io_service run() function. When a handler throws an exception the run function throws that exception too. Multiple threads call the run function in a try catch block. To restart the event handler I need to call run again but the documentation stated that restart() has to be called first. Restarting the io_service must assure that all run calls has been finished. How can I do that when other threads are still calling the run function?
To restart the event handler I need to call run again but the documentation stated that restart() has to be called first.
No the documentation does not say that. You need to reset once the service had run out of work/been stopped. You did neither, so you do not need reset there.
Simply do as explained in this post Should the exception thrown by boost::asio::io_service::run() be caught? (which links to the docs)
Related
I want to be able to catch any attempts of executing exit()/ExitProcess()/TerminateProcess() or any other such calls.
I thought about registering a handler with atexit(). This works fine for normal program termination (return from main()) or exit() calls (regardless of the thread that calls exit()), but ExitProcess() and TerminateProcess() bypass the handler I registered.
ExitProcess() documentation states:
Note that returning from the main function of an application results
in a call to ExitProcess.
But the observed behaviour is at least different in this regard.
Is there a method of registering a handler for process exit/termination what will always be called (except for external calls to TerminateProcess(), unhandled exceptions thrown by one of my threads or __failfast() calls, I'm guessing these are really impossible to catch).
There is the dirty option of hooking ExitProcess(), but I'd rather not do that.
EDIT: just so this is clear: I'm interested in my own process, not monitoring / controlling another process.
There is a Kernel Mode Event a device driver can subscribe to in order to get notifications of terminations of processes. This is preferred over trying to inject a DLL into processes for API hooks due to the myriad number of internal and external ways that process may end.
I know Windows seperatly builds a Structered Exception Handling Chain for each running thread within a process. I was wondering if with veh, the registered exception handler will be called process wide (no matter in what threat the exception occured) or was also registered on a per thread basis?
Yes, vectored exception handlers are process wide.
From MSDN:
An application can register a function to watch or handle all
exceptions for the application. Vectored handlers are not frame-based,
therefore, you can add a handler that will be called regardless of
where you are in a call frame.
New Vectored Exception Handling in Windows XP by Matt Pietrek states:
The handler list is not tied to any thread, and is global to the
process.
assume I have a thread which is still running when the application is terminating
(This thread can not terminate because it waits for a Windows api call to return
and that can be long...)
What happens to the thread if the application is closed ?
Can it raise an exception (I'm under Delphi) ?
I'd say that an exception is very plausible. When you call Application.Terminate this will lead to the following sequence of events:
A call to PostQuitMessage.
Application.Terminated being set to True.
Application.Run returning.
System.Halt is called.
Exit procedures are run, specifically DoneApplication which will tear down Application and all components that it owns. Hmm, better hope your thread does not access anything owned by Application.
FinalizeUnits is called. Uh-oh. Memory manager is shut down, and lots more beside.
ExitProcess is called. Now your thread is killed.
Your thread will carry on running until the call to ExitProcess. If it executes any code at all that would be affected by the calls to DoneApplication and FinalizeUnits, then you should expect problems.
A windows service program is implemented by deriving from ServiceBase class with C#. The service will load an assembly with a background thread in OnStart() and start from a function entry point through an InvokeMember() call. Inside the assembly dll/background thread, the program will allocate various system resources during its running. Now the problem is that the OnStop() implemented as a NOP, so there is no hook I can use. Without changing the OnStop() implementation, how do I clean up allocated resources when the service is stopped by "sc stop aService"?
I tried various ways but looks like there is no way to intercept "sc stop" message besides changing OnStop(). I tried to add a try/catch/finally block with a backgroud cleanup thread but I can't get the finally clause called. Tried AppDomain UnhandledException and ProcessExit handlers and that did not do anything either. So what're the effects of a SERVICE_CONTROL_STOP(sc stop) on background threads? Is there anyway I can clean up resources within my assembly/dll at all?
Whenever a Windows Azure role is stopped its OnStop() method is invoked. Turns out that there's RoleEnvironment.Stopping event that is triggered before OnStop() is invoked. MSDN says this event is the right place for role clean shutdown code.
What's the difference between the two? Why would I put role clean shutdown code in Stopping event and not in OnStop() method override?
Besides the fact that the event mechanism provides a flexible way to attach handlers, while the OnStop method has to be defined directly on the class derived from RoleEntryPoint, one relevant difference is this:
The Stopping event is not raised when the virtual machine of the role
instance is rebooted.
So the stopping event will not be raised, for instance, when the VM is rebooted for guest OS upgrade.
Another difference is this:
Code running in the OnStop method has 5 minutes to finish when it is called
for reasons other than a user-initiated shutdown.
While there is no mention in the documentation that the Stopping event has such a limit.
Source:
MSDN - RoleEnvironment.Stopping Event
MSDN - RoleEntryPoint.OnStop Method
Events allow other subscribers in other classes to perform some action, whereas the method allows the subclass author such as yourself to place it in the actual class and (for example) modify which events get raised.
Brent Stineman (Windows Azure MVP) recently blogged about the RoleEntryPoint and related start/run/stop sequence, and describes both Stopping and OnStop in the sequence descriptions.