I am writing a program which runs 3 parallel processes, each one receiving commands from the user. But I need to run 3 command prompts, one for every process, and I'm not sure how that's coded in C.
To get that to work in a single terminal, you have to:
Ensure that at most one of the three processes is reading at a time.
Ensure that the prompt for the process that is reading is displayed (not the prompt for some other process).
Ensure that the user is very alert and aware of what they're typing.
The first two are non-trivial technical problems requiring inter-process coordination (communication). The last is not soluble.
As a UI design, that sounds extremely ... sub-optimal.
If you use multiple terminals, then the process-level coordination issues go away; each process works with its own terminal window and the system handles the coordination. The user, though, has to switch between the different windows to enter the correct data now, so you still have problem 3. As a UI design, that still sounds ... sub-optimal.
Related
I'm just wondering if it is possible to create two children processes, and in both of these processes ask the user for input? Or would it be stuck waiting forever?
It depends on the precise implementation of “asking user for input”. If this is readline, which implements shell-like input with the prompt and editing, it won’t work. The reason is that the library messes up with the terminal configuration. If two processes are doing the same thing simultaneously they will step on each other’s foot.
If we are talking about simply reading from standard input, that will work, but with a few quirks. First, without external synchronization it’s not known in which order processes are going to consume the input. It is even possible that process A grabs a few chunks from the input line, while process B grabs the rest.
Second, standard streams are buffered, therefore a process might consume more input than immediately obvious. E.g. the program reads a single line of input, but internally more data is read from the OS, since there’s no way to ask for bytes until the new line. The other process reading input simultaneously won’t get the input the other process consumed, even if the later only done it due to buffering and didn’t use the input.
To conclude, probably better to avoid having multiple processes consume input simultaneously.
I have a homework.
each application must wait for each of their activity.
I can write this scenario as pthread however, I must to write this scenario with different application.
I can write application as pthread with following code;
pthread_mutex_lock(&mutex2);
printf("I am in i");
pthread_mutex_unlock(&mutex2);
requested to me ; Users run application as following format;
./application 1
./application 2
./application 3
1,2,3 represented thread id value, and each application includes loops, each application in order to run code.
second application will not start until finish first loop of first application, and third application must wait end of first loop of first and second application.
how can i write this application ?
Thanks
The behavior you desire can be implemented by means of interprocess communication (IPC). It may be implemented, say, by means of shared memory with bool flag located in it. I don't know what OS you're going to write your app for, so can say nothing more specific at the moment.
Judging from "./" and pthread I suggest target OS is one of the *nix family, but you'd better clarify it. If it is the case, shmget and company may suit your needs.
And by the way, you wrote you're going to start app like this:
./application 1
./application 2
./application 3
which means they will run exactly one after another, otherwise you'd start them in the background:
./application 1&
If you do have to run them exactly like you described, then you'll have to fork and exit from parent in order to return control to shell and run your loop in the child process.
Again, this is relent for *nix systems with bash-like shell.
I am creating a c program that is called periodically. But upon meeting some conditions it might call a functions that uses X11 to create a window. That window will listen to events hence have a loop that waits for the events. So my C program has to wait till the created window finished doing its job. How do I make my program to call the function[defined in another c file] that creates the window and exit?
UPDATE: I was thinking of creating a socket between my C cron job and the server that handle creating the window and does what is instructed by the user. A good idea?
cron doesn't normally have access to either a terminal or your X display. If you want it to, you'll have to figure out all the bits necessary for it to work (starting with setting DISPLAY, but possibly needing to delve into xauth and other things, and deciding what needs to be done when the display is not running, or locked, or running a different user, or ...) and incorporate all that in a script that then calls your program.
If the fork and exec patter is used just to run a program without freeze the current program, what's the advantage, for example, over using this single line:
system("program &"); // run in background, don't freeze
The system function creates a new shell instance for running the program, which is why you can run it in the background. The main difference from fork/exec is that using system like this actually creates two processes, the shell and the program, and that you can't communicate directly with the new program via anonymous pipes.
fork+exec is much more lightweight than system(). The later will create a process for the shell, the shell will parse the command line given and invoke the required executables. This means more memory, more execution time, etc. Obviously, if the program will run in background, these extra resources will be consumed only temporarily, but depending on how frequently you use it, the difference will be quite noticeable.
The man page for system clearly says that system executes the command by "calling /bin/sh -c command", which means system creates at least two processes: /bin/sh and then the program (the shell startup files may spawn much more than one process)
This can cause a few problems:
portability (what if a system doesn't have access to /bin/sh, or does not use & to run a process in the background?)
error handling (you can't know if the process exited with an error)
talking with the process (you can't send anything to the process, or get anything out of it)
performance, etc
The proper way to do this is fork+exec, which creates exactly one process. It gives you better control over the performance and resource consumption, and it's much easier to modify to do simple, important things (like error handling).
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Linux API to list running processes?
How can I detect hung processes in Linux using C?
Under linux the way to do this is by examining the contents of /proc/[PID]/* a good one-stop location would be /proc/*/status. Its first two lines are:
Name: [program name]
State: R (running)
Of course, detecting hung processes is an entirely separate issue.
/proc//stat is a more machine-readable format of the same info as /proc//status, and is, in fact, what the ps(1) command reads to produce its output.
Monitoring and/or killing a process is just a matter of system calls. I'd think the toughest part of your question would really be reliably determining that a process is "hung", rather than meerly very busy (or waiting for a temporary condition).
In the general case, I'd think this would be rather difficult. Even Windows asks for a decision from the user when it thinks a program might be "hung" (on my system it is often wrong about that, too).
However, if you have a specific program that likes to hang in a specific way, I'd think you ought to be able to reliably detect that.
Seeing as the question has changed:
http://procps.sourceforge.net/
Is the source of ps and other process tools. They do indeed use proc (indicating it is probably the conventional and best way to read process information). Their source is quite readable. The file
/procps-3.2.8/proc/readproc.c
You can also link your program to libproc, which sould be available in your repo (or already installed I would say) but you will need the "-dev" variation for the headers and what-not. Using this API you can read process information and status.
You can use the psState() function through libproc to check for things like
#define PS_RUN 1 /* process is running */
#define PS_STOP 2 /* process is stopped */
#define PS_LOST 3 /* process is lost to control (EAGAIN) */
#define PS_UNDEAD 4 /* process is terminated (zombie) */
#define PS_DEAD 5 /* process is terminated (core file) */
#define PS_IDLE 6 /* process has not been run */
In response to comment
IIRC, unless your program is on the CPU and you can prod it from within the kernel with signals ... you can't really tell how responsive it is. Even then, after the trap a signal handler is called which may run fine in the state.
Best bet is to schedule another process on another core that can poke the process in some way while it is running (or in a loop, or non-responsive). But I could be wrong here, and it would be tricky.
Good Luck
You may be able to use whatever mechanism strace() uses to determine what system calls the process is making. Then, you could determine what system calls you end up in for things like pthread_mutex deadlocks, or whatever... You could then use a heuristic approach and just decide that if a process is hung on a lock system call for more than 30 seconds, it's deadlocked.
You can run 'strace -p ' on a process pid to determine what (if any) system calls it is making. If a process is not making any system calls but is using CPU time then it is either hung, or is running in a tight calculation loop inside userspace. You'd really need to know the expected behaviour of the individual program to know for sure. If it is not making system calls but is not using CPU, it could also just be idle or deadlocked.
The only bulletproof way to do this, is to modify the program being monitored to either send a 'ping' every so often to a 'watchdog' process, or to respond to a ping request when requested, eg, a socket connection where you can ask it "Are you Alive?" and get back "Yes". The program can be coded in such a way that it is unlikely to do the ping if it has gone off into the weeds somewhere and is not executing properly. I'm pretty sure this is how Windows knows a process is hung, because every Windows program has some sort of event queue where it processes a known set of APIs from the operating system.
Not necessarily a programmatic way, but one way to tell if a program is 'hung' is to break into it with gdb and pull a backtrace and see if it is stuck somewhere.