Hello,
in the application i'm writing i need to launch "recordmydesktop" to capture the screen,but i'm having a problem: when the recording stops,and the encoding of the saved file starts,the entire system hangs until the completion of the encoding.This happens if i launch recordmydesktop from my application (simply by clicking a button).
Now what is weird is:if i start recordmydesktop by opening a shell and starting it manually (with my app already running),the encoding doesn't generate any hang.....
The only difference i noticed is the different priority level that recordmydesktop gets when starting from the shell,which is lower than my app's one (i.e. a higher priority number),while when i start it from my app it gets the same of my application,which has a higher priority level.
I tried to start recordmydesktop using the fork and exec approach,giving a lower priority with the "nice" system call,but nothing seems to be better.....
Do you have any advice?
Thanks in advance!
An update: i found out about the "chrt" shell command. It actually did the job:i assigned to recordmydesktop a much lower priority,and now it doesn't hang the system anymore.
But....
1)Is this way to proceed correct? I ask cause changing scheduling policies and priorities does sound "dangerous" if i don't know exactly what's happening
2)Starting recordmydesktop with the fork-exec mechanism makes me feel like i have kinda lost control of it.... I mean,how can i know when this "child" process ends its execution? I could save,for example,the pid of it and later check if a process with that pid is active...but to me it doesnt sound like a good way to control it....
As a rule, UNIX systems will accept anything reducing its own priority with the glee of something being given free money, but demand root of things that would increase their priority. It is never dangerous to give a process a lower priority unless the process itself is something time-critical; burning CDs at low priority would mean more coasters than usual for example. But a low-priority gzip would just work slower if other things were competing for time. See the nice and renice commands for other traditional methods of changing a process' priority.
I'm wondering though, what priority is it being reduced from? Did it have ludicriously high priority in the first place, to halt your system like that? What user was your GUI running it as?
Lastly, I must wonder precisely by which mechanism this recordmydesktop process was ever started if not fork/exec
The main app's priority is -2 with a ROUND_RR scheduling policy,and it must be run by root user,or it won't work (i cant change this).If i remember well,it's the highest priority i can see using the "top" command,so this explains why my system halted (does it?).
Before,i started it calling the "system" function,but after some readings i found out that it's not a suggested way to run external programs,for some problems related to the shell it's based on,so i passed to fork/exec.
fork() is the only way to create a new process, so system() ultimately uses it anyway. But yes, it creates and runs a shell in the process, which is a bit messy and has a performance cost. This means fork()/exec() is actually far more direct than system(), not the other way around. You can find out when a child has finished with the waitpid() call.
-2 is actually a lower priority, not a higher one; the higher the number, the higher the priority. What priority and scheduler did you modify it to to get it to function, exactly?
Oh i'm such a newbie I got confused with the niceness concept,which has a reversed logic (higher number <=> higher niceness <=> lower priority)....
About your question:i honestly don't know very well how the original programmer has set the program's priority,but,using the "chrt -p" command i found out it has a SCHED_RR policy with a priority 0.
I have then used the chrt command to set the child process' policy to SCHED_OTHER (which forces me to use a 0 priority).So i guess that what made it work is the fact that i downgraded the child process from real time to normal (but i'm not sure...can you confirm that?)
... It may be I got it exactly backwards. 'top' on my system shows a few kernel things which I expected to have high priority but may actually have had low priority. Argh. I'll need to do more research into priority myself since there seems to be two seperate kinds.
I'd suggest changing the priority to 0 without changing the scheduler.
Different systems use priority differently and this results in the contradictory information. A bit of standardization comes from the parameters to nice and renice: a positive parameter makes the process less important (is nice to other processes). Negative niceness makes the process more important. But what values show up in the kernel depends of who wrote the kernel.
Somewhat universally, there must be two forms of priorities. The first, a scheduling priority helps decide the relative importance of processes on the run queue. This kind of priority is affected by nice and by how much cpu the process tries to use.
The second kind of priority is based on any in-progress system call. When a process, regardless of its first type of priority, issues, for example, a mkdir() system call, it suddenly gets a very high "second kind" priority. Once a mkdir() starts, it must be allowed to complete, or the file system will be damaged. The priority must be so high that the process is unkillable during the system call. Ideally this should last only a fraction of a second.
Users cannot affect the second type of priority. So you can't issue a nice() system call to render your particular mkdir() unimportant and interruptible. (And I'm using mkdir() simply as an example.)
These two types of priorities have varying names on different OS's and many times it seems to me that the names should be switched. So, yeah, some confusion exists here...
