all I some question for Akka child actor life cycle.
I know that the lifespan of a child actor cannot be longer than that of a parent actor.
In this case child actor will exit?
CASE
If the parent actor exits while the child actor is working, will the child actor abandon the job he is processing and the job he is planning to handle and exit?
Documentation
A child actor can be forced to stop after it finishes processing its
current message by using the stop method of the ActorContext from the
parent actor. Only child actors can be stopped in that way.
In other words, the child does finish the current message (if it is processing one). (It would be hard to do otherwise without killing the thread and that has lots of problems.) Essentially a flag is set that will break out of the loop that processes messages.
After the current message, however, the actor will stop, abandoning its mailbox. You still have opportunity to clean up in a PostStop, however.
Related
I am writing a server. It uses fork() to create new child processes. I want to kill the child processes when a parent process dies. I am planning to use an array to store the pids of the child processes.But there is chance that the child process might terminate before the parent process. In this case if we call kill function using SIGKILL and pid of the child process that already terminated, will it throw an exception?
When a child process terminates, a SIGCHLD signal is sent to the parent. You can handle this signal in the parent to check what child has terminated on it's own, before you got a chance to wait for it. And you should wait() for all children to avoid zombie processes.
You can also take a look at this thread for an alternative way to have the children terminate when the parent terminats: How to make child process die after parent exits?
Parent process launches a child process by invoking CreateProcess() method which returns immediately even before the child process is initialized. How do I make the parent process wait until the Child process got initialized and started executing? WaitForSingleObject() call makes the parent process to wait until the child thread terminates or until timeout.
Is there any similar method which makes the parent process to wait until the child process is intialized?
You can create a named event in WinAPI in the parent process and set it to unsignalled state. Call WaitForSingleObject on the event handle. Then in the child process you can open event by name and signal it (call SetEvent()) after the child process is initialized.
If you are using threads, one of the simpliest way to make parent thread wait until the child finishes is using .join() function. In the parent process's end use
child.join();
I'm writing this with c++ on Ubuntu 12.04 LTS and i am explicitly not using any BOOST libraries.
What I want to do is have a parent process and two or more children run simultaneously.
The parent process acts like an event listener and task dispatcher. The children handle the tasks the parents tells them to; these tasks are system calls, and the parent doesn't care when they finish.
What I have done successfully so far is
parent will fork() some children and retain their pids
children are suspended (S) immediately after being fork() with pause()
parent resumes (R) and detects events in a standard event loop way
what I need to know next is how to resume a child and return to the parent while child is still running.
So my questions are, can a parent and child run simultaneously and safely in this manner? (where the parent doesn't care what the child is doing after its resumed)
What do I have to do to in general to resume a child process after a pause()?
below is the constructor function that forks the children
childManager(int number_of_children, pid_t parent) {
int i=0;
while(number_of_children--) {
if(parent == getpid())
{
this->parent = parent;
children.push_back({++i,_IDLE,fork()});
if(parent != getpid()) pause();
}
}
}
The only question I see here is
What do I have to do to in general to resume a child process after a pause()?
Send it a signal whose action is either to execute a signal-catching function or terminate the process. For example:
kill(children[i], SIGUSR);
That said, this is a less than ideal way to do this. You could just as easily have the children block on a pipe waiting for the parent to tell them to do something. Or about 30 similar things which don't involve signals.
To answer your specific questions:
So my questions are, can a parent and child run simultaneously and safely in this manner? (where the parent doesn't care what the child is doing after its resumed)
The parent process will have to call wait or waitpid to harvest the child processes after they exit. If you do not do that you will be left with zombie processes. You can do this in a nonblocking way inside your event loop in the parent process.
What do I have to do to in general to resume a child process after a pause()?
You have to send a signal to the child process. You do this by calling kill in the parent process. You will need to install a signal handler in the child process to catch the signal - use sigaction for that.
As part of a Linux benchmark application, I have a parent process that forks multiple children that will each perform a task in parallel. I'm using signals to coordinate between them since I'm looking for as accurate of timing as possible. Each child will prepare for the test, then enter a 'barrier' controlled by the parent via signals.
Once all the children have entered the barrier, the parent records the time stamp, and signals the child processes to begin. As soon as the child finishes each portion of the test they signal the parent before entering the next barrier. The parent is listening for these signals and once it receives them from all of the child processes, it records the completion time(s).
My problem is that the program terminates non-deterministically; the signals don't always get delivered. The signal handler could not be any simpler:
void sig_child_ready (int sig)
{
num_child_ready++;
}
num_child_ready is declared as volatile sig_atomic_t. I've tried using sigprocmask without success in a loop like this:
sigprocmask (SIG_BLOCK, &mask, &oldmask);
while (num_child_ready < num_child)
{
/* waiting for child signals here */
sigsuspend (&oldmask);
}
sigprocmask (SIG_UNBLOCK, &mask, NULL);
I'm not sure how to proceed from here. Am I correct that sigprocmask is needed to 'queue' the signals so they are processed one by one?
Or, consider this hypothetical scenario: the parent receives a signal, is executing its handler, then receives ANOTHER identical signal. Is the signal handler called recursively? ie will it execute the second handler before returning to, and completing the first handler?
I'm just looking to make sure all of the signals are delivered as synchronously as possible.
Normal signals are not queued, and that's likely the cause of your problem.
If one signal arrives before the handler has been run for a past signal, they'll get merged and there's little you can do about that - you're probably better off using some other form of IPC to do this kind of synchronization.
You could use "realtime signals", which do get queued. You'd send signals with sigqueue() and
"receive" them with sigwaitinfo() or establishing a signal handler setting the SA_SIGINFO flag in a struct sigaction
I have a worker thread in my application, which occasionally recieves information that should be quickly displayed in QML UI. When I have such portion of information, I emit signal, which is received by object that lives on UI thread.
I want this process to be very responsive, so that changes are displayed in QML UI as quickly as possible (this matters because worker thread handles external controller, and I want the shortest "critical path" between user interaction with controller and UI change).
However I discovered, that the time difference between emit signal() and slot called in UI thread is always 20-40 milliseconds. Why so?
What can I do to speed up this? I tried calling QCoreApplication::processEvents() in worker thread after signal is emitted, but this barely changes anything.
Some thoughts:
Can I call processEvents but for UI thread somehow?
Use event with high priority instead of signal. Will it help?
OS: Win8.1, Qt 5.5
When you emit a signal from a worker thread to the UI thread, it is put into the UI event queue, and delivered when the event queue is pumped and reaches that message. If your worker thread is a higher priority than your UI thread, then the UI thread will have to wait until the worker thread blocks. If the worker thread is the same priority it will complete it's time quanta, which may be 20ms. You can make your signal connect Direct rather than Queued, and then you will need to take care of thread safety yourself.