I have a shared object that I have written which I link to an Linux executable (say a game for example). Now when the program finishes (game over!), what kind of signal handler should I have in my shared object that I created in order to perform some cleanup activities?
Please remember that I DO NOT have control over the Linux executable, it is a game that I simply download from the Internet and run it by linking it to my shared object. When the game finishes, I want to be able to catch that event and do some cleanup activities.
Have I made my question clear? Any ideas?
Thanks,
Krishna
if you run the game as a child process, you'll get SIGCHLD (17) when the other process ends.
If the main application uses the standard C library, then you can make use of the atexit(3) function to register a function to be called when the application exits.
There are a number of cases where the function will not be called though (abnormal termination through signals, a call to _exit(2), etc), so check the man page to see if all your use cases are covered.
In general, you can't do this from within the process. (Software can't have dying wishes.)
However, you could run the existing game process inside a wrapper script or something that runs another program after the game finishes:
#!/bin/sh
run_game
perform_cleanup_activity
Related
I'm writing a DLL (in Visual C++) and I recently decided that I need to move stuff that currently happens in threads into their own process. This is because I want to support multiple instances of the DLL being loaded and running. However, they all need to access the same group of resources (i/o buffers to a COM port) that needs to be autonomously monitored as long as there is at least one instance of the DLL running.
It seems I need to use CreateProcess(), but I'm unclear on how I should use the lpApplicationName argument. In the examples I've seen, the name of an existing program gets passed, but that isn't what I imagine I need to do. I expected to be able to start a process by specifying a function, much like with CreateThread(). The process doesn't need to be compiled and output as its own executable, does it? It definitely shouldn't be used by anything other than my DLL. Thanks.
EDIT: Okay, so if all CreateProcess() can do is start a pre-existing program, how can I get this to work? If the following happens:
Process loads the DLL
DLL starts port monitoring threads
Second process loads the DLL
Second DLL establishes some IPC to access the same data as the first DLL
First DLL is about to exit, and terminates the monitoring threads
Second DLL starts its own monitoring threads and continues
Doing 5 and 6 seems (especially with my implementation) like a clunky way of doing things, rather than just have behavior that I never have to terminate and restart.
EDIT: The more I think about this, the more I like the idea of making a separate executable, but if anyone think of a more "elegant" method, I'd still like to know.
You can't do that. On *nix you could fork can then call whatever function you want, but CreateProcess doesn't work that way. The only thing CreateProcess can do is launch a new process with execution starting at the entry point of an on-disk executable.
System / software Details :
Qt Version 4.7.4
Linux
Kernel : 2.6.31 (Custom kernel built for IMX25)
Peripherals :
Graphic LCD (64x128)
Quectel (M 12) GPRS module
Thermal printer
Database : Sqlite3
I am a beginner don't have much experience either in Qt or programming with Linux. I have developed an application where user enter some data manually and that data gets saved in sqlite database. So what I am trying to do is that after certain time lets say 90 seconds data from database should get transferred to the server using the GPRS.
So I am using the Qt's signal and slots mechanism to do the timed data transfer. I have created a slot which gets fired every 90 seconds and as the slot gets fired I am creating/launching a POSIX thread which is suppose to transfer the data to the server.
So what that thread does is it launches the "pppd" and once the "pppd" is up it queries the database for the data and sends the data to the server. And once the data transfer is done I kill the "pppd". The functionality works fine.
But the problem is that the "pppd" takes time to launch so I had to introduce some delay. i.e sleep of 12 seconds is there in order to let the pppd launch successfully. But as the sleep is blocking it makes the main program/thread non responsive until the "pppd" is launched (i.e. it halts/stops all the activities like printing etc.). And as the "pppd" is launched the main thread becomes responsive again.
So please suggest me some solution in order to keep the main thread responsive when "pppd" is launching or please suggest me if there is any other alternative for the same. Also guide me if there's anything wrong with my approach..
Thanks in advance. And I am sorry if I have not followed your standards..
There are several options available to you. It looks like you're using a thread, but then calling sleep in the main thread, which is basically the same as not using thread to do your work at all! You need to leverage Qt processes as illustrated below:
You can use a QProcess in which you start() and use the signal finished() to notify the main thread that it is complete. This is probably what you want to use. All you have to do is:
QProcess *proc = new QProcess;
proc->start("theProcess", QStringList() << "the" << "arguments");
connect(proc, SIGNAL(finished()), this, SLOT(someSlotToUse()));
This sequence of code will start a new process with your arguments, and then call someSlotToUse() when the process is complete.
You can use a QThread along the same pattern.
Basically, what you're trying to do is do the work in another thread, keeping the GUI reactor free to process GUI events rather than long queries. This is a classic problem in Qt and there is a lot of literature out there.
Alternately, you can use a QProcess::concurrent() call, which allows you to run a function in another process, but I've never tested it.
Here are some references for you to look at: Qt Concurrent, QProcess, and QThread
My goal is to set virtual memory page permissions (as if the forked process called mprotect) from the parent process. Can this be done with ptrace(1) or by some other magic?
Thanks!
It can be done (via ptrace() indeed; gdb can do this), but not without a lot of finagling, since in order to call a function in another process, you basically have to setup its registers and stack, etc. for execution, and then continue the process, which will execute the function. One program I know off the top of my head that might have some useful source/methodology for you to look at is injectso. If you do look at injectso, look at the inject_code() functions.
In addition, calling conventions vary by platform, so you'd have to re-jigger your code for each architecture/OS, etc.
I'm running a long process in the background. I've managed to output the console data to gui. But the problem is that, the data is returned only after the process is finished. But I need to display the data at realtime. ie, I need to display the data, every time it produces some output on the console. I'm running the process with in my gui from a seperate thread.
I mean, it would be like building a gui for the ping command, where output is displayed on console after each packet is send, ie at realtime. I just need to redirect that to gui, in realtime. I'm implementing the gui in wxwidgets. Any help would be greatly appreciated.
Thanking You..
Jvc
Is the output you wish to display generated in a separate process from the process running the GUI? Or in a separate thread in the same process?
I ask because most people, when they ask this question, mean a a separate thread. Since you have tagged your question with "process" I will assume that is what you mean.
You need some inter-process communication. There is a bewildering variety of techniques to do this. Personally, I always use sockets.
wxWidgets has simple, easy to use socket classes wxSocketClient and wxSocketServer.
The background process is probably not running wxWidgets, so you will need something else there. I reccomend boost::asio. I know it looks intimidating, but in fact the tutorial code can be used as is.
There is a lot more to be said, but I risk straying away from the point, since there are so few details in your question.
You can have an output queue protected by a wxMutex. The thread doing the computation writes to the queue, then signals the GUI thread using wxQueueEvent with a custom event to let it know that the thread is not empty. The GUI thread then reads the queue and outputs the data.
I have an existing utility application, let's call it util.exe. It's a command-line tool which takes inputs from the command line, and creates a file on disk, let's say an image file
I want to use this within another application, by running util.exe. However it needs to be synchronous so the file is known to exist when processing continues.
e.g (psudeo)
bool CreateImageFile(params)
{
//ret is util.exe program exit code
int ret = runprocess("util.exe",params);
return ret==0;
}
Is there a single Win32 API call that will run the process and wait until it ends? I looked at CreateProcess but it returns as soon as it tries to start, I looked at ShellExecute but that seems a bit ugly even it were synchronous.
There's no single api, but this is actually a more interesting general question for Win32 apps. You can use CreateProcess or ShellExecuteEx and WaitForSingleObject on the process handle. GetExitCodeProcess at that point will give you the program's exit code. See here for simple sample code.
However this blocks your main thread completely, and can give you serious deadlock problems under some Win32 messaging scenarios. Let's say the spawned exe does a broadcast sendmessage. It can't proceed until all windows have processed the message - but you can't proceed because you're blocked waiting for it. Deadlock. Since you're using purely command line programs this issue probably doesn't apply to you though. Do you care if a command line program hangs for a while?
The best general solution for normal apps is probably to split a process launch-and-wait off onto a thread and post a message back to your main window when the thread runs to completion. When you receive the message, you know it is safe to continue, and there are no deadlock issues.
Process handle is a waitable object, AFAIK. This is exactly what you need.
However, I'd recommend against doing anything like that. Starting process on windows may be slow and it will block your UI. Consider a PeekMessage loop with 50ms wait timeouts to do it from a windows application.