My aim: I want to pass a signal (int-type variable) to another running console program.
My idea: Write the data to the disk, and read the data by the other console program.
Possible defect: Too slow, and not efficient.
Is it able to pass "(self-defined / int-type) signals" to another console program ?
Any suggestion (or a better workaround way) would be appreciated.
Yes...
Option 1: Use SendMessage() to send a message to the other process' message queue. (Probably not suitable since you said you have a console program, and it probably doesn't have a message queue.)
Option 2: Use named shared memory.
Option 3: Use a named pipe between the two processes.
Option 4: Use a UDP or TCP network connection between the two processes.
Option 1 is the simplest/easiest, but requires that the target process have a running message queue to receive and process the message.
It depends on what you actually want to pass between the processes involved. If all you need to do is notify the other process, that something has happend (and the other process has the means to find out about the details itself right after being notified), then a named event might be what you need.
If you need to share more information, consider shared memory and mapped files.
Of course, you may also consider to go down the COM route. Define an interface for the process, which should receive the "signal" and have it register an object in the global object table. The sending process can obtain the instance from the object table and use the interface to perform the notification.
There may be countless other ways.
I think we can also pass any signals to any applications in linux using kill .just see 'man kill' for example sending SIGKILL to keil we can write like ..
kill -9 keil
by using kill -l we can see all signals and their respective numbers. and pass their like this 'kill -n app_name'
Related
I'm using C and Winsock2 for my learning project.
I have some questions that I hope some one can confirm.
Let say I have 2 unrelated processes, process A and process B ( without using CreateProcess ). By unrelated I mean it's not parent and child.
1)
Is it possible in Windows to Accept a socket in process A and pass it to process B if they are unrelated?
2)
I guess i have to use WSADuplicateSocket? but that only works for related processes?
I hope someone can explain and confirm the above..
Is it possible in Windows to Accept a socket in process A and pass it to process B if they are unrelated?
Yes, via WSADuplicateSocket():
The WSADuplicateSocket function is used to enable socket sharing between processes. A source process calls WSADuplicateSocket to obtain a special WSAPROTOCOL_INFO structure. It uses some interprocess communications (IPC) mechanism to pass the contents of this structure to a target process, which in turn uses it in a call to WSASocket to obtain a descriptor for the duplicated socket. The special WSAPROTOCOL_INFO structure can only be used once by the target process.
I guess i have to use WSADuplicateSocket?
Yes.
but that only works for related processes?
No. It will work fine between any 2 processes, as long as process A knows process B's Process ID, as that is a required parameter of WSADuplicateSocket().
My app is suppose to run long term (usually idling). If I try to open a second app (or trigger the app via global hotkey) I'd like my existing instance to receive some kind of IPC message and bring itself to the front. How do I do this on linux? The problem I've been running into is if I hold a global lock it doesn't automatically free when the instance close (usually I unlock it but an app can crash). If I try to use mkfifo I have no idea if I'm the first instance or not and every solution I can think of seems to require a lot of code and usually that's a sign to me I might be doing something wrong
There are many IPC primitives, all possible to use.
A simple one is using a named pipe: If the pipe doesn't exist then the program creates it and starts as usual. Then it polls the pipe at regular intervals to see if something can be received on the pipe, in which case the program receives it (and discards it) and puts itself to the "front".
If, on the other hand, the named pipe exists, then the program sends a simple dummy message through it, and exits.
I would use a flag file, e.g. /run/service-name/pid with PID of the first running instance. A new instance would check this file, if it does not exists, create it, if it does, send a SIGUSR1 to the PID in the file.
#Some programmer dude's answer above provides a bit more of flexibility.
int uv_process_kill(uv_process_t* handle, int signum)
Sends the specified signal to the given process handle. Check the documentation on uv_signal_t — Signal handle for signal support, specially on Windows.
int uv_kill(int pid, int signum)
Sends the specified signal to the given PID. Check the documentation on uv_signal_t — Signal handle for signal support, specially on Windows.
Are these two ways of doing the exact same thing, or is the mechanism inside the library somehow different? I need to handle the error condition where my UV loop may have failed to run (for whatever reason), but I have already called uv_spawn for all the processes I wish to spawn.
My goal is to clean up the resources allocated to the child processes, without needing to know if the uv loop is running, stopped or in an error state.
uv_process_kill and uv_kill perform the same action, but they differ from each other because of their interface. The former accepts an uv_process_t handle while the latter requires a pid explicitly (both have a second argument that is a signal number).
It's worth noting that the struct uv_process_t (that you can use with uv_process_kill) has a field named pid (that you can use with uv_kill), thus one could argue that the two functions are redundant.
Anyway, the pid of the process to be killed could come to hand because of an external source (as an example, an user could provide it through the command line - think at how the kill tool works on Linux). Therefore, there is no guarantee that you have an instance of uv_process_t whenever you have a pid and it goes without saying that the two functions serve slightly different purposes.
Of course, you can still use uv_kill when you have an instance of uv_process_t as:
uv_kill(proc.pid);
Anyway this is not the way libuv works and you should ever use the functions that accept uv_* data structures when you have them, for they know how to tear down everything correctly.
To sum up, you can think at uv_process_kill as a more libuv oriented function to be used when you are in charge of the whole lifecycle of the process (you spawn it and you kill it if needed). On the other side, uv_kill is a more general purpose function to be used when you want to deal with processes of which you know the pid but for which you don't have a properly initialized uv_process_t.
Look at the source (here and here). uv_process_kill and uv_kill do the same thing.
When ever C program exectues it produces error or executes sucessfully. If it produces error I am redirecting the error to a file error.log. I want a Signal (notification) to be generated as soon as a write action takes place on error.log, this signal should invoke another program say, Parser.c which will read the error.log copy into buffer and clear the contents of log file.
Is it possible that a file generates a signal to invoke another program if yes then how can we achieve it programmatically?
I believe the answer will be different on different systems. I would suggest that you just start that other program from the first program (fork a new process on Linux) after you are done writing on file.
One way would be to use the asynchronous I/O mechanism (aio_*), these will send a signal as specified in the AIO control block (check the man page for further details, it's pretty complete). Essentially you would be setting up an AIO control block for reading, and issue an aio_read(). When the signal is received, you would process the data. aio(7) for Linux is a pretty useful man page regarding this.
This is for an assignment I'm working on, and NO I'm not looking for you to just GIVE me the answer. I just need someone to point me in the right direction, maybe with a line or two of sample code.
I need to figure out how to set the priority of a file read operation from within my program. To the point:
server process receives a message and spawns a child to handle it
child tries to open the filename from the message and starts loading the file contents into the message queue
there may be several children running at the same time, and the initial message contains a priority so some messages may get more device access
The only way I can think to do this (right now, anyways) would be to increment a counter every time I create a message, and to do something like sched_yield after the counter reaches a given value for that process' assigned priority. That's most likely a horrible, horrible approach, but it's all I can think of at the moment. The assignment is more about the message queues than anything else, but we still have to have data transfer priority.
Any help/guidance is appreciated :)
Have the pool of child processes share a semaphore. Once a child acquires the semaphore it can read a predefined number of bytes from the resource and return it to the client. The number of bytes read can be related to the priority of the request. Once the process has read the predefined number of bytes release the semaphore.
Until recently, there was no IO prioritization in Linux. Now there is ionice. But I doubt you are meant to use it in your assignment.
Are you sure your assignment is talking about files and not system V message queues?
Read the man pages for:
msgctl(2), msgget(2), msgrcv(2), msgsnd(2), capabilities(7),
mq_overview(7), svipc(7)
Although I think you can use a file as a key to create a message queue, so that multiple processes have a way to rendezvous via the message queue, a Sys V message queue itself is not a file.
Just wondering because you mention "message queues" specifically, and talk about "priorities", which might conceivably map to the msgtyp field of eg. msgsnd and msgrcv, though it's hard to tell with what information you've given what the assignment really is about.