I'm writing some dll (on windows in MSVC++2008) which provides some functionality as xmlrpc server. To implement xmlrpc server I'm using xmlrpc-c library.
I can start xmlrpc server in some diffrent ways. More intresting are:
run method - This will run xmlrpc server forever so dll can't control until server is not terminated.
runOnce method - This will run xmlrpc server only to process one RPC. And if there is no request it will wait for that.
I can't keep control in dll for long time. I need to process some RPCs and give back control to program which is using dll. And process next RPCs when dll will get back control again.
runOnce looks ok. But there is possibility that there will be no RPCs to process and it will be waiting for one. That is unacceptable.
There is also one exception:
runOnce aborts waiting for a
connection request and returns
immediately if the process receives a
signal. Note that unless you have a
handler for that signal, the signal
will probably kill the whole process,
so set up a signal handler — even one
that does nothing — if you want to
exploit this. But before Xmlrpc-c 1.06
(June 2006), signals have no effect —
there is no way to make runOnce abort
the wait and return.
Can I use it as workaround go get back control to dll? Is it possible to send signal from dll to themself? How it works on windows?
Or maybe there is some better solution of this issue?
Signals (of the kind that makes an Xmlrpc-c library call abort early) don't exist in Windows.
Best solution is to create new thread for server.
Related
I'm using blocking sockets API (waitFor* functions) for sending mail by smtp protocol (it's a DLL modue). All operations are synchronous: connect->waitForConnected(timeout)->login->waitForReadyRead(timeout)->sendMessage->waitForBytesWritten(timeout)->etc.
I'm using blocking API, because QCoreApplication absence is required (DLL used by different apps, incl. non-qt-based). Blocking functions don't require event loop and it works fine.
But how can I make a visual progress for long-term sending mail operations (with big attachment, for example)?
And how can organize callbacks for progress notifications in sendmail DLL?
ps: all blocking waitFor* functions marked as
functions, that may fail randomly on Windows. Consider using the event loop and the readyRead() signal if your software will run on Windows.
Why?
You can definitely have a QApplication instance when using DLLs (it must be QApplication not QCoreApplication since you want a widget-based gui). It integrates into the native message loop of the main thread. Remember that for Qt Gui to run you only need a native event loop - the code doesn't have to be stuck within QCoreApplication::exec. You need an instance of the application, and you need to prime it by invoking exec once, and ensuring that it returns (i.e. by using a zero-timeout timer), but that's all. Past that, the application's main thread's message pump will handle things for you.
Furthermore, to use networking APIs, you don't need to be stuck in the main thread - you can handle them in a separate thread.
Your DLL won't be compatible with console applications that don't run a message pump in the main thread, but then you can cheat: on Windows, and on Windows only, the QCoreApplication and its derived classes can be used in any thread :)
You definitely must either statically link your DLL with Qt, or use a dynamically-linked Qt that was put in a unique namespace. Remember that if the application you link with uses Qt, there are absolutely no guarantees that the Qt they built is binary-compatible with the Qt that you use. Even if it's the same version.
I have written a c++ program which has a infinite loop. I want to run this program as a daemon (or service) in linux.
I want to communicate with this running daemon from outside of program (for example console or another program).
I read about signal handling in c++ and apparently there are some predefined signals. Is there any way to send your own signal to the running program?
Signals are most probably not what you really want to communicate with a demon process, unless you want to terminate it in a specific manner.
Also no, you can't define your own arbitrary signal numbers, as the operating system needs to know how they are sent to the process. As mentioned in my comment there are the SIGUSR1 and SIGUSR2 were intended for user defined signalling purposes.
The easiest way to let an external process communicate with a demon process, is to give it a configuration file, and let the demon watch for changes using the inotify() interface.
This technique is also used by many system demons already.
You can use kill(pid, signal) from one process to send signal to another. Sending SIGKILL will violently and instantly terminate your process.
Signals are limited to what they express - and you can find that out by accessing page 7 of signal manual. Some signals can be ignored/handled/blocked while others cannot.
If you want true custom inter-process communication you should use pipes or even sockets (bad practice). This way, you would have to define your own protocol and you can do a lot more than with signals.
Here's a tutorial on how to use named pipes to send data to running processes: http://www.linuxjournal.com/content/using-named-pipes-fifos-bash.
My application throws some strange errors if you shut down the computer while my application is running.
Sometimes the message is (address) memory can not be "read", sometimes can not be "write".
Shutting down the application in the normal way doesn't generate such messages.
How can I simulate the "windows shutdown" so that I can debug my application? How can I find out what the application is trying to do that it cannot?
When Windows wants to shutdown, it sends a series of events to the application; such as WM_ENDSESSION and WM_QUIT. You can process these in the message handler you are using; in general the application will need to respond appropriately and quickly to these messages else the OS will just terminate the application anyway. I'm not sure what default processing wxwidgets offers in this regard. Hooking into these would help in diagnosing the application error itself.
There are a few things you could attempt to do;
The shutdown sequence will not be easy to simulate (if at all) - a lot happens during shutdown; the exact state and situation is difficult to simulate in it's entirety.
In terms of diagnosing the state of the application just before shutdown, you could try to process the WM_QUERYENDSESSION and respond with a FALSE to prevent it from shutting down (with newer versions of Windows you can no longer prevent the shutdown, so it may not work depending on the platform you are on).
You could also try to test the application's immediate response to WM_ENDSESSION message by sending it the WM_ENDSESSION (e.g. via a PostMessage) with the appropriate data as detailed on MSDN.
For terminal based applications;
You can also hook in the signals (SIGKILL I believe) if required. See this Microsoft reference for more detail. You can also the the SetConsoleCtrlHandler hook. But since you using a toolkit, it would be better to use the messages sent to the application already.
Is it possible to have a program restart automatically if it crashes?
Something like:
An unhandled exception is thrown.
Release all resources allocated by process.
Start over and call main.
I would like this behavior for a server application I'm working on. If clients miss use the server it can get a std::bac_alloc exception, in which case I would like the server to simply restart instead of crashing and shutting down, thus avoiding manual startup.
I've done this before in Windows by running said program from another program via a win32 CreateProcess call. The other program then waits on the "monitored" process to exit, and calls its CreateProcess() again if it does. You wait for a process to exit by performing a WaitForSingleObject on the process' handle, which you get as one of the return values from your CreateProcess() call.
You will of course want to program in some way to make the monitoring process shut itself and its child process down.
Let Windows be your watchdog. You can call ChangeServiceConfig2 to set the failure actions for your service. (If your server isn't a service, then you're doing it wrong.) Specify SERVICE_CONFIG_FAILURE_ACTIONS for the dwInfoLevel parameter, and in the SERVICE_FAILURE_ACTIONS structure, set lpsaActions to an array of one or more SC_ACTION values. The type you want is SC_ACTION_RESTART.
I did something similar by implementing a watchdog. The watchdog ran as a service and would wait for a ping (called petting the dog) from the monitored process. If the monitored process died due to an exception, watchdog would cleanup and relaunch the application.
In case the application was not responding(no ping in a certain time) the watchdog would kill it and then restart it.
Here is a link to an implementation that you might want to use:
http://www.codeproject.com/KB/security/WatchDog.aspx
(PS: I implemented my own version but I cannot post it here. I found this from a quick google search and have no first hand experience with this particular implementation.)
If you just catch the exception, it should be possible to just restart your server by internal programming logic without completely restarting the whole program.
Like #T.E.D., we've done this in an application we built. Our application is a windows service, so the helper program stops the service (eventually kill it, if it hangs) and start the service again.
I'm developing a DLL in C++ which needs to write some data via a (previously established) TCP/IP connection using the write() call. To be precise, the DLL should send a little 'Process 12345 is terminating at 2007-09-27 15:30:42, value of i is 131' message over the wire when the process goes down.
Unfortunately, all the ways I know for detecting that the process is ending are apparently too late for any network calls to succeed. In particular, I tried the following approaches and the write() call returned -1 in every case:
Calling write() from the destructor of a global object.
Calling write() from a callback function registered using atexit().
Calling write() from DllMain (in case the reason argument is DLL_PROCESS_DETACH). I know that this is not a safe thing to do, but I'm getting a bit desperate. :-)
I'm aware that a DLL can't detect any process shutdown (it might have been unloaded long before the process terminates) but since the shutdown data which the DLL needs to send depends on other code in the DLL, that's acceptable. I'm basically looking for the latest moment at which I can safely perform network IO.
Does anybody know how to do this?
Consider monitoring the process from a separate watchdog process.
Determining If a Process Has Exited: http://msdn.microsoft.com/en-us/library/y111seb2(v=VS.71).aspx
Tutorial: Managing a Windows Process: http://msdn.microsoft.com/en-us/library/s9tkk4a3(v=VS.71).aspx
Consider to use Windows Job Objects.
You main program (monitoring program, which will use for example send()) can start child process suspended, place it into a Job and then resume. Then it will run in the job object. You can register notification via SetInformationJobObject with JobObjectAssociateCompletionPortInformation. Then you will be notified if in the job will be created some child process and if some process inside of job will be ended. So you will be able to send all what you need from the monitoring process. If you debug a program in Visual Studio it uses also job objects to have control under your process and all child processes which you start.
I successfully use the technique in C++ and in C#. So if you will have some problem with implementation I could post you a code example.
I suggest taking option 3. Just do your DLL loading/unloading properly and you're fine. Calling write() should work, I can't explain why it's not in your case. Is it possible that the call fails for a different reason that is unrelated?
Does it work if you call your DLL function manually from the host app?
Why? Just close the socket. If that's the only close in the program, which by your description it must be, that tells the other end that this end is exiting, and you can send the process ID information at the beginning instead of the end. You shouldn't do anything time-consuming or potentially blocking in an exit hook or static destructor.
Where is Winsock being shut down using WSACleanup? You need to make sure that your I/O completes before this happens.
You should be able to work out if this is happening by placing a breakpoint on the Win32 call in Winsock2.dll. Unload of DLLs is displayed in the output in the debug window.