I'm writing my own shell in c, and problem is in implementation of background process.
Now on BASH whenever we execute a process ending with '&' then that process goes in background
and start executing, Output of background process comes on terminal and when background process needs input then it is suspended until we give "fg" command.
So how to implement background process?
For any normal execution of commands (not ending with &) I call fork system call, and then in child process I execute the command, parent will wait for execution of child process(by wait()).
And for commands having '&' I done same thing but parent will not wait for execution of child process. Here my problem is whenever background process needs input it take control over terminal. so how to suspend child process when it needs input.
To detach the process from the parent, you need to use setsid() on the children process, it will run the program in new session
sid = setsid();
See also http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html
Related
There is this answer for python from an old thread which I used in the past to great effect (see first answer here How to prevent a block of code from being interrupted by KeyboardInterrupt in Python?). I'd like to know if it is possible to do something similar in Julia.
That's pretty much it, but here's some background.
I'm developing a Markov Chain Monte Carlo algorithm in Julia and I need to insure that the state of the chain is always valid, especially following a Ctrl+C/SIGINT. This is particularly important during development in the REPL where I want to be able to stop the chain but then restart it where it was left off without having to start from scratch and wait for the burn-in period all over again.
As it stand it is almost always the case that the chain will be in an invalid state following a SIGINT.
In other words I want to have blocks of code that are uninterruptibles, namely critical blocks within which a SIGINT is deferred until the block has terminated.
Ctrl+C/SIGINT causes the InterruptException, so you can place your code within a try block and catch the InterruptException.
try
# ... your algorithm here ...
catch e
if e isa InterruptException
save_your_chain_to_a_valid_state()
then_exit()
else
rethrow()
end
end
If you're running the code outside of the REPL, you'll first have to call Base.exit_on_sigint(false) before the try block.
disable_sigint prevents a block of code to be interrupted immediately, whereas catching InterruptException is a mean to handle the interrupt:
try
disable_sigint() do
for i in 1:5
sleep(1)
print(".")
end
end
println("\nnow it is safe to interrupt immediately")
while true
sleep(1)
print("*")
end
catch InterruptException
println("interrupt catched")
end
If running a script remember how to catch Ctrl-C:
julia -e 'include(pop!(ARGS))' script.jl
disable_sigint is able to mask the InterruptException generated by a SIGINT signal (for example a signal coming from a
kill command on unix). For example if the running code is notified throwing directly an interruptException() it is interrupted as soon as possible ignoring the disable_sigint directive.
This may be the case of a jupyter environment where communication between client and kernel processes happens through a IPC channel (ZeroMQ transport channel) or the case of vscode where a "supervisor" process manage a child julia execution context.
Chances are that the kernel interrupt command delivered from jupiter frontend to jupyter kernel backend that "supervises" julia code is not delivered to child process using a SIGINT OS-signal.
I'm learning about fork(), exec(), etc. and I ran into something in a textbook that I don't fully understand.
In the example, a process calls fork().
In the child process, we call exec().
Later, in the parent, we call wait().
It is my understanding that a successful exec() call never returns. If we called exec() in the child, how can we wait for the child to return in the parent, if the child will never have control returned to it from the exec()?
My only guess here is that what happens is the parent, thinking it's waiting on the child, is actually waiting on the new process created with exec? I.e. normally I'd fork() and wait for the child. If I fork() and exec the UNIX program date then wait for the child in the parent, am I actually now waiting for date to exit?
Thanks!
You need to distinguish the process from the program. Calling exec runs a different program in the same process. The exec function doesn't return (except to signal an error) because it terminates the program that calls in. However, the process is reused to run a different program. In a way, from the perspective of the process running exec, the exec function returns as the entry point of the new program.
From the point of view of the parent, there's a child process. That's all the parent knows. The parent doesn't know that the child called exec, unless it watches it and finds out by indirect means such as running ps. The parent is just waiting for the child process to exit, no matter what program the child process happens to be running.
My Qt 4 application can only update the log box area (actually the whole GUI) until a function finishes execution. Is there any way to update the GUI/log box during the execution? Like adding something like QWidget::repaint() or QWidget::update() in the for loop, so the user can see that the GUI is processing, rather than wait until the function finishes and print out the log at once.
You need to occasionally call QCoreApplication::processEvents() during the execution of your function. This will keep the GUI alive and responsive by letting the event loop run.
An alternative is to execute your function in a separate thread. More information on threads in Qt can be found here: http://qt-project.org/doc/qt-4.8/threads.html.
when using FlexPrintJob, after calling start(), a OS system print interface will appear, and at the same time Flex code execution will be paused, and it will remain paused until user finished interaction with the OS print dialog. the problem is I do have data from server, and the connection will time out within certain period, so is there any walk around to not pause the Flex code execution while OS print dialog is popped up. Thanks.
From the doc for FlexPrintJob:
You use the FlexPrintJob class to print a dynamically rendered document that you format specifically for printing.
This makes me wonder if you couldn't (essentially) fork off a second page from the browser that contains your print job and do the printing from there. This would leave your original page still running. In my flex apps I do this via PHP (create additional pages for printing and such). Example here.
Otherwise: you should finish all the server data d/l before starting the print job to avoid this issue.
Flex is only just recently starting to add multi-threading. It's adding worker threads of a sort but this won't help what you're asking for.
In my program I am executing long lived tail (with -f) via execl.
Anything after that call to execl does not get executed.
Do I need to call/execute this tail in background so that I can do other things in my program?
I usually exit out of my program by ctrl C.
execl() will replace the calling process, so your calling program won't exist anymore once you've called it.
To get around this, you could call execl() after a call to fork(). Fork splits your program in two (a parent and a child), and you'll be able to check which is the child process and which is the parent. This example explains how to use fork - in the second example there, you'd put your execl() call inside the child process section.
The man page for the exec family of calls starts with:
The exec family of functions replaces
the current process image with a
new process image.
Not entirely sure what you want to accomplish, but it looks like exec isn't the solution. If you want your first program to remain alive, you'll need to fork. Does your initial program do something with the output of tail -f?
If your parent program would like to capture the output from tail, you should look a the popen() function. This will start the tail process and the output can be read from the FILE* it returns.
If your parent program has no interest in capturing the output then you'll want to create a child process using fork() which then calls execl(). The child process image will be replaced by tail and your parent process will continue.