I am writing a program that launches several child processes through fork() and needs to periodically track which CPU they are on. Is there any way to accomplish this in C?
I am aware of cpu_getaffinity(), but that's within the process itself. I would like to be able to call a function that would let me know what CPU a child process is running on based on the PID, and I haven't been able to find anything quite related to that.
The closest I've found is to access the /proc/ filesystem, but is there a way to do it within the program and not looking through an external system?
check it in parent process through /proc interface
check it in child processes, and send it back to parent process through IPC, such as shared memory or socket, etc..
Related
I know there's another thread with the same name, but this is actually a different question.
When a process forks multiple times, does the parent finish executing before the children? Vice versa? Concurrently?
Here's an example. Lets say I have a for loop that forks 1 parent process into 4 children. At the end of that for loop, I want the parent process to feed some data to the children via pipes. The data is written to each child process' respective stdin.
Will the parent send the data first, before any of the children execute their code? This is important, because we don't want it to start working from an invalid stdin.
The order of the execution is determined by the specific OS scheduling policy and not guaranteed by anything. In order to synchronize the processes there are special facilities for the inter-process communication (IPC) which are designed for this purpose. The mentioned pipes are one example. They make the reading process to actually wait for the other process to write it, creating a (one-way) synchronization point. The other examples would be FIFOs and sockets. For simpler tasks the wait() family of functions or signals can be used.
When a process forks multiple times, does the parent finish executing before the children? Vice versa? Concurrently? -
Concurrently and depends on the scheduler and its unpredictable.
Using pipe to pass integer values between parent and child
This link explains in detail about sharing data between parent process and child.
Since you have four child process you may need to create different individual pipes between each child process.
Each byte of data written to a pipe will be read exactly once. It isn't duplicated to every process with the read end of the pipe open.
Multiple child processes reading/writing on the same pipe
Alternatively you can try shared memory for the data transfer.
They will execute concurrently. This is basically the point of processes.
Look into mutexes or other ways to deal with concurrency.
I have an application which uses mmap for ipc. Can I run this application multiple times? Will it have any side effects ?
My application scenario:
my application forks off a child process whose job is to always kill the parent process randomly but it should do this in controlled manner, for example setting a variable in parent process which indicates the child process to kill the parent process (here comes the mmap). The parent process has a signal handler where it can resume the application again the child process kills the parent process it continues...
Can any one help me? thanks in adavnce
Whether running your application multiple times will have side effects or not depends on how you implement it. Please have a look at this answer. It contains a lot of helpful information. For example:
mmap is great if you have multiple processes accessing data in a read only fashion from the same file [...]
This mean: If you want to use the same shared memory for multiple parent/child pairs, then you need to synchronize access to that shared memory. Please have a look at this Q&A on how to do that. Of course, you have to make sure, that each parent/child pair uses its own variables in the shared memory.
Another option is to use a separate shared memory segment for each parent/child pair. You could do this, for example, by making the process ID of the parent process a part of the shared memory file name. Then, when you fork the child process, you pass the process ID (or the shared memory file name) to the child process, so that parent and child know which shared memory to use in order to comunicate to each other.
I am writing a program in C on a linux machine and I need to get information about a child process. I am trying to use getrusage(), but can't seem to get any valuable information. Is there any way I can get the usage statistics (and any other information) of a child process from the parent process given the child's process id?
Note that the POSIX definition of getrusage() clearly indicates that you can only get the information for child processes that have terminated, not for still running child processes. There's also a caveat that you have to be paying attention to dying children; if you're ignoring the SIGCHLD signal, you won't get data from getrusage() for them.
If you need information about still-running processes, you'll need to grovel around the /proc file system for the information for the relevant children; there probably isn't another way to do it.
You could use IPC to communicate between your processes. Otherwise if you only need the information after the child terminated, you can use the waitpid() call.
I am doing quite a lot of forking in a process (and the children of that process are further forking), and I want to keep an acceptable limit on the total number of processes I create.
Is there a (preferably efficient) way of finding the total number of children of a process (including children of children, children of children of children, etc.) from C?
I would like my code to work on both linux and mac, so no /proc I'm afraid!
There is no way to enumerate all the children of a process, except by enumerating all the processes of the system and checking their PPID. (Of course, from the parent itself, you can just keep track of what you fork.) There is no way at all to enumerate all the descendants of a process: if P forks Q forks R then Q dies, there is no more information to relate P with R.
The portable way to obtain information about processes is to call the ps utility and parse its output.
If you want to limit the number of descendants of a process, you can do it easily by using a dedicated user to run that process, and starting the ancestor with the desired limit on processes per user (setrlimit(RLIMIT_NRPROC, …)).
You can also use a shared resource of some kind; this will work as long as the descendant processes don't close that resource. For example, you can open a file (without the O_CLOEXEC flag), if the descendants don't call fcntl with the FD_CLOEXEC flag on that file nor just go and close it. I think that on OSX you'll need to fork fuser or lsof (either will work on Linux too) to find out how many processes have the file open, I don't know of a way to do that without forking on OSX. You might investigate other mechanisms such as shared memory (shm_open and friends) or memory mappings (mmap and friends), but for these I don't know of a way to get the use count without forking either.
There is no portable API to do, what you're asking for. C itself doesn't even define the concept of processes and the process management APIs of an operating system are very specific and usually not portable.
Either you find a portable abstraction library for what you want to do, or you implement it yourself.
check this. if you can create a variable shared between all processes then you can moniter the number of processes based on that shared counter value.
even this answer can help you in creating a shared variable.
You could open up a pipe or socket in the root process, and have each child write to it when they're created and when they exit. If you want to limit the total number of descendant processes, you could have children check with the root process before they fork, rather than notifying it after.
My question is about more philosophical than technical issues.
Objective is to write a multiprocess (not multithread) program with one "master" process and N "worker" processes. Program is linux-only, async, event-based web-server, like nginx. So, the main problem is how to spawn "worker" processes.
In linux world there are two ways:
1). fork()
2). fork() + exec*() family
A short description for each way and what confused me in each of them.
First way with fork() is dirty, because forked process has copy (...on-write, i know) of parent memory: signal handlers, variables, file\socket descriptors, environ and other, e.g. stack and heap. In conclusion, after fork i need to...hmm..."clear memory", for example, disable signal handlers, socket connections and other horrible things, inherited from parent, because child has a lot of data that he was not intended - breaks encapsulation, and many side-effects is possible.
The general way for this case is run infinite loop in forked process to handle some data and do some magic with socket pair, pipes or shared memory for creating communication channel between parent and child before and after fork(), because socket descriptors reopen in child and used same socket as parent.
Also, this is nginx-way: it has one executable binary, that use fork() for spawn child process.
The second way is similar to first, but have a difference with usage one of exec*() function in child process after fork() for run external binary. One important thing is that exec*() loads binary in current (forked) process memory, automatic clear stack, heap and do all other nasty job, so fork will look like a clearly new instance of program without copy of parent memory or something other trash.
There has another problem with communication establishing between parent and child: because forked process after exec*() remove all data inherited from parent, that i need somehow create a socket pair between parent and child. For example, create additional listen socket (domain or in another port) in parent and wait child connections and child should connect to parent after initialization.
The first way is simple, but confuse me, that is not a clear process, just a copy of parent memory, with many possible side-effects and trash, and need to keep in mind that forked process has many dependencies to parent code. Second way needs more time to support two binary, and not so elegant like single-file solution. Maybe, the best way is use fork() for process create and something to clear it memory without exec*() call, but I cant find any solution for second step.
In conclusion, I need help to decide which way to use: create one-file executable file like nginx, and use fork(), or create two separate files, one with "server" and one with "worker", and use fork() + exec*(worker) N times from "server", and want know for pros and cons for each way, maybe I missed something.
For a multiprocess solution both options, fork and fork+exec, are almost equivalent and depends on the child and parent process context. If the child process executes the parents' text (binary) and needs all or a part of parents' staff (descriptors, signals etc) - it is a sign to use fork. If the child should execute a new binary and needs nothing from the parents' staff - it seems fork+exec much more suitable.
There is also a good function in the pthread library - pthread_atfork().
It allows to register handlers that will be called before and after fork.
These handlers may perform all the necessary work (closing file descriptors, for example).
As a Linux Programmer, you have a rich library of multithreading process capabilities. Look at pthread and friends.
If you need a process per request, then fork and friends have been the most widely used since time immemorial.