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.
Related
I have a server program(compile by g++) which is running. And I change some code and compile a new bin file. Without kill the running process, I mv the new created bin to overwrite the old one.
After a while, the server process crashed. Dose it relate to my replace action?
My server is an multi-thread high concurrent server. One crash is segfault, other one is deadlock.
I print all parameters in the core dump file and pass them exactly same to the function which was crashed. But it is OK.
And I carefully watch all thread info in the deadlock core dump, I can not find it is an possibility to cause deadlock.
So I doubt the replacement will cause strange things
According to this question, if swap action is happen, it indeed will generate strange things
For a simple standard program, even if it is currently opened by the running process, moving a new file will first unlink the original file which will remain untouched apart from that.
But for long running servers, many things can happen: some fork new processes and occasionally some can even exec a new fresh version. In that case, you could have different versions running side by side which could or not be supported depending on the change.
Said differently, without more info on what is the server program, how it is designed to run and what was the change, the only answer I can give is maybe.
If you can make sure that you remove ONLY the bin file, and the bin file isn't used by any other process (such as some daemon). Then it doesn't relate to your replace action.
I built a modular program consisting of several programs (exe), and in some cases these modules are also in DLL. There are about 6 modules.
All of these modules used functions of a Thread. This thread does not use visual components, what it does is basically analyze huge files (> 1GB).
To improve the efficiency and organization, extract all the code relating to this file analysis, which is used by each of the modules. This facilitates updating and find error.
The threads worked normally before, no code change, except as necessary to adapt them to the DLL project.
Now, when I run the procedures of Thread, everything functions normally except the synchronize () method, which freezes without making errors or lock the main program.
The synchronize () method is used because the threads are created entirely within the DLL. Therefore, the main program is called a procedure DLL, which creates and runs the thread, without any intervention by the main program.
For this procedure are passed several parameters, one of them is a type "pointer to procedure" ^procedure, who is using it as an event, fired by the thread through the synchronize () periodically, ensuring that during the performance, which lasted more than one hour in most sometimes, if track progress, see errors errors among others.
I searched on google but did not find information except someone saying that possibly the synchronize () method is waiting for the main process that is not responding for unknown reasons.
Note: The main program and the window does not lock or freeze; only the thread that does not call / run procedure provided to synchronize (); I confirmed it!
Added
Nota2: I want to avoid as much use PostMessage () or similar, because it forces me to include LCL, which makes the DLL file up from the current 300K to 2MB (in release mode). Apart from that there are reports that its operation is not good as expected.
That is because you have two complete instances of everything (RTL,LCL etc). One set in the DLL, one set in the EXE. Both code and data.
You are probably calling the synchronize of the DLL, which schedules it for the LCL loop in the DLL which does nothing, since all work is done in the EXE.
This will be very hard to fix, basically you need packages for this. Partially also because the thread involvement will further complicate it because of threadvariables (Thread local storage) that is set up potentially differently for DLL and EXE threads.
For this one needs packages which is only in its initial stages and solves this by having only one copy of everything. See the link for a deeper treatise.
I am looking to make an application in Linux, where only one instance of the application can run at a time. I want to make it robust, such that if an instance of the app crashes, that it won't block all the other instances indefinitely. I would really appreciate some example code on how to do this (as there's lots of discussion on this topic on the web, but I couldn't find anything which worked when I tried it).
You can use file locking facilities that Linux provides. You haven't specified the language, however you might find this capability pretty much everywhere in some form or another.
Here is a simple idea how to do that in a C program. When the program starts you can take an exclusive non-blocking lock on the whole file using fcntl system call. When another instance of the applications is attempted to be started, it will get an error trying to lock the file, which will mean the application is already running.
Here is a small example how to take the full file lock using fcntl (this function provides facilities for putting byte range locks, but when length is 0, the full file is locked).
struct flock lock_struct;
memset(&lock_struct, 0, sizeof(lock_struct));
lock_struct.l_type = F_WRLCK;
lock_struct.l_whence = SEEK_SET;
lock_struct.l_pid = getpid();
ret = fcntl(fd, F_SETLK, &lock_struct);
Please note that you need to open a file first to put a lock. This means you need to have a file around to use for locking. It might be useful to put the it somewhere where it won't cause any distraction/confusion for other applications.
When the process terminates, all locks that it has taken will be released, so nothing will be blocked.
This is just one of the ideas. I'm pretty sure there are other ways around.
The conventional UNIX way of doing this is with PID files.
Before a process starts, it checks to see if a pre-determined file - usually /var/run/<process_name>.pid exists. If found, its an indication that a process is already running and this process quits.
If the file does not exist, this is the first process to run. It creates the file /var/run/<process_name>.pid and writes its PID into it. The process unlinks the file on exit.
Update:
To handle cases where a daemon has crashed & left behind the pid file, additional checks can be made during startup if a pid file was found:
Do a ps and ensure that a process with that PID doesn't exist
If it exists ensure that its a different process
from the said ps output
from /proc/$PID/stat
I'm using 3.9.7 cURL library to download files from the internet, so I created a dynamic bibioteca of viculo. dll written in C using VC + + 6.0 the problem is that when either I call my function from within my vb6 application window locks and unlocks only after you have downloaded the file how do I solve this problem?
The problem is that when you call the function from your DLL, it "blocks" your app's execution until it gets finished. Basically, execution goes from the piece of code that makes the function call, to the code inside of the function call, and then only comes back to the next line after the function call after the code inside of the function has finished running. In fact, that's how all function calls work. You can see this for yourself by single-stepping through your code in the VB 6 development environment.
You don't normally notice this because the code inside of a function being called doesn't take very long to execute before control is returned to the caller. But in this case, since the function you're calling from the DLL is doing a lot of processing, it takes a while to execute, so it "blocks" the execution of your application's code for quite a while.
This is a good general explanation for the reason why your application window appears to be frozen. A bit more technically, it's because the message pump that is responsible for processing user interaction with on-screen elements is not running (it's part of your code that has been temporarily suspended until the function that you called finishes processing). This is a bit more difficult for a VB programmer to appreciate, since none of this nitty-gritty stuff is exposed in the world of VB. It's all happening behind the scenes, just like it is in a C program, but you don't normally have to deal with any of it. Occasionally, though, the abstraction leaks, and the nitty-gritty rears its ugly head. This is one of those cases.
The correct solution to this general problem, as others have hinted at, is to run lengthy operations on a background thread. This leaves your main thread (right now, the only one you have, the one your application is running on) free to continue processing user input, while the other thread can process the data and return that processed data to the main thread when it is finished. Of course, computers can't actually do more than one thing at a time, but the magic of the operating system rapidly switching between one task and another means that you can simulate this. The mechanism for doing so involves threads.
The catch comes in the fact that the VB 6 environment does not have any type of support for creating multiple threads. You only get one thread, and that's the main thread that your application runs on. If you freeze execution of that one, even temporarily, your application freezes—as you've already found out.
However, if you're already writing a C++ DLL, there's no reason you can't create multiple threads in a VB 6 app. You just have to handle everything yourself as if you were using another lower-level language like C++. Run the C++ code on a background thread, and only return its results to the main thread when it is completely finished. In the mean time, your main thread is free.
This is still quite a bit of work, though, especially if you're inexperienced when it comes to Win32 programming and the issues surrounding multiple threads. It might be easier to find a different library that supports asynchronous function calls out-of-the-box. Antagony suggests using VB's AsyncRead method. That is probably a good option; as Karl Peterson says in the linked article, it keeps everything in pure VB 6 code, which can be a real time saver as well as a boon to future maintenance programmers. The only problem is that you'll still have to process the data somehow once you obtain it. And if that's slow, you're right back where you started from…
Check out this article, which demonstrates how to asynchronously transfer large files using a little-known method in user controls.
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.