I was reading about pipes today, it seems an interesting for me to use it or to start about it.
but it's written there that the processes should be like a parent and child or client server and the communication will be between them.
there are some things I don't understand and before start I should be sure about them.
If I have a running process for example on my machine, and I want to send message to it, of course I can't control it, so how can I make it respond to my messages??
should I create the client and server and run them both??
Or the running process application can be a server for example and I can send some events to it??
if you can help me in this :)
thanks :)
If the running process is reading from stdin, you may write to /proc/the_pid/fd/0 to send your message.
Related
Is it possible to get HANDLES of all running processes of my application?
I need to send message to all currently running processes of my application. Every process may execute from a different location (folder/filename) and may be a different version of the same application. Other applications should never receive my messages.
Originator itself shouldn't receive a message, only other instances should receive a message. New instances of my application start in future also should communicate with other currently running copies.
Main window class and name may differ, so FindWindow() is not a solution for me.
How can I do this? What is the best way to solve this task?
I have a C++ Qt application which works with daemon (spnav) - receives X11 messages from it. Is it possible to receive some kind of notification, if daemon crashes? I know that I can create loop in separate thread, but I must operate only with one thread. Does Linux (or X11, or someone else) send any broadcasts when application crashes?
Thanks to #y_ug, I have found a solution - start the daemon process as a child of my program.
I am searching for a way to close a process running under any user by a windows service running under the system account. I've nearly tried everything but I could not find any solution except killing the process.
Why can't I kill the process?
I can't kill the process uses a tray icon. If I kill the process, the tray icon won't disappear.
What I've tried so far
I've already tried to use global eventhandles (did not work because the child process got extremely laggy).
I also tried to use PostMessage/SendMessage to communicate with the process. That solution did not work because a windows service can not interact with any user interfaces,...
I found another question (here on stackoverflow) which describes exactly my problem: Close a child process from a windows service.
This question does not contain a nice solution.
First of all I don't use C++ instead of C#. The next problem is, that the child process uses a mouse hook. So it has so run very fast without many overhead. Otherwise it would get laggy which would mean, that the mouse would lag on the whole system.
So is there really no simple solution to close a process from a windows service?
A service can use SetProcessWindowStation() and SetThreadDesktop() to attach to the interactive desktop of the target process before then sending messages to the target process.
Alternatively, the service can use CreateProcessAsUser() to run a new process in the same session as the target process, and then that process can send messages to the target process.
I am writing a simple web server with C++ that handles long-lived connections. However, I need to reload my web server from time to time. I wonder if there is a way that I can hand over the established connections from one process to another process to be able to retain my established connections after reload.
Would that be enough to only pass file descriptors? what would happen to connection states?
Any similar open source project that does the same thing?
Any thoughts or ideas?
Thanks,
I really have no idea whether this is possible, but I think not. If you fork() then the child will "inherit" the descriptors, but I don't know whether they behave like the should (though I suspect that they do.) And with forking, you can't run new code (can you?) Simple descriptor numbers are process-specific, so just passing them to a new, unrelated process won't work either, and they will be closed when your process terminates anyway.
One solution (in the absence of a simpler one,) is to break your server into two processes:
Front-end: A very simple process that just accepts the connections, keep them open and forwards any data it receives to the second process, and vice versa.
Server: The real web server, that does all the logic and processing, but does not communicate with the clients directly.
The first and second processes communicate via a simple protocol. One feature of this protocol must that it does support the second process being terminated and relaunched.
Now, you can reload the actual server process without losing the client connections (since they are handled by the front-end process.) And since this front-end is extremely simple and probably has very few configurations and bugs, you rarely need to reload it at all. (I'm assuming that you need to reload your server process because it runs into bugs that need to be fixed or you need to change configurations and stuff.)
Another important and helpful feature that this system can have is to be able to transition between server processes "gradually". That is, you already have a front-end and a server running, but you decide to reload the server. You launch another server process that connects to the front-end (while the old server is still running and connected,) and the front-end process forwards all the new client connections to the new server process (or even all the new requests coming from the existing client connections.) And when the old server finishes processing all the requests that it has under processing, it gracefully and cleanly exits.
As I said, this is a solution you might to try only if nothing easier and simpler is found.
I would like to write a server application which has a read in of the users commands but still outputting new events during the read in. It should look like e.g. the Minecraft server console.
I tried some things but nothing worked and I'm out of ideas.
Check out
http://www.amazon.com/Pocket-Socket-Programming-Kaufmann-Practical/dp/1558606866
This is a great guide to learning sockets.
I would look start with the very simple TCP Listener example in the book.
You'll want your server to listen to a socket, read (parse) user commands, and respond accordingly.
If you're not tied to C++, you can do this pretty darn quickly with a Perl/Python/Ruby or even C#.
Read about libedit or GNU Readline.