Hi Brian, On Fri, 2003-02-07 at 14:17, [EMAIL PROTECTED] wrote: > Should be. But it might lag while it waits for disk i/o or something.
Could be... But this never happens in practice actually. Anyway, I see your point and it's valid. > This is the wrong approach. If you have to do this, then there is a > bug in lavplay. Why not address the real problem instead of hacking > around it? The idea is that there is no issue in lavplay that triggers this. > Wrong. You did not read all of my message carefully. I will explain > again. When you issue the "kill(0,9)" you are not just killing > lavplay but every process in the same process group! > > This is not just the child processes of glav, but also glav's parent > and any children of that parent that have not issued their own > setpgrp()! To show you an example of what that means (I do not mean > to sound condecending, but you didn't seem to understand the > ramifications when I explained them in my last message): > > # ps -eo pid,ppid,pgrp,tty,args | less > PID PPID PGRP TT COMMAND > 1 0 0 ? init > 2 1 1 ? [keventd] > 3 1 1 ? [ksoftirqd_CPU0] > 4 1 1 ? [kswapd] > 2260 1 2260 ? gnome-terminal ... > ... > 2311 2260 2311 pts/1 bash > ... > 17403 2311 17403 pts/1 /bin/bash /home/brian/bin/edlit test.mov > 17410 17403 17403 pts/1 glav --size 640x480 test.mov > 17411 17410 17403 pts/1 lavplay -q -g --size 640x480 test.mov > 17412 17411 17403 pts/1 lavplay -q -g --size 640x480 test.mov > 17413 17412 17403 pts/1 lavplay -q -g --size 640x480 test.mov > 17414 17412 17403 pts/1 lavplay -q -g --size 640x480 test.mov > 17415 17412 17403 pts/1 lavplay -q -g --size 640x480 test.mov > ... > > As you can see, glav was started by a shell script (PID 17403), which > was started by an interactive shell (PID 2311), which was started by a > "gnome-terminal" (PID 2260). > > When the interactive shell starts (PID 2311) it starts a new "process > group", in this case, process group 2311. All processes that inherit > from that shell, unless they issue a setpgrp(), will have the same > process group id. > > But notice that the shell script that started glav created a new > process group (PGRP 17403), but glav _did_not_. So when glav issues a > kill(0,9) every process with PGRP == 17403 will be killed with a > SIGKILL, and that includes the process that started glav (and any > other processes that that shell script may have started -- none in > this example)! > > glav has no business killing any processes except those that it > spawned. It should really only kill (nothing IMHO, but if you > insist,) the children it knows it's responsible for, which is "pid" > (the same "pid" that glav does a "waitpid" on directly after killing > it). > > If you really want to keep the kill(), please either: > > a. change the first argument of kill() from 0 to pid or Sounds good. > b. if you sill want that "wide sweeping" kill, at least have glav > create a new process group with setpgrp(), or Nah... > c. alternatively change the first argument of kill() to -1 or Erm... POSIX 1003.1‐2001 requires that kill(‐1,sig) send sig to all processes that the current process may send signals to, except possibly for some implementation‐defined system processes. Linux allows a process to signal itself, but on Linux the call kill(‐1,sig) does not signal the current process. (man 3 kill) I personally would love to try this out, but I don't think end users will appreciate it. [-cut-] I'm all in for changing the first argument to pid. Changing to SIGINT isn't actually that much of a good idea, since lavplay grabs SIGINT to close down. SDL actually does the same thing which even complicates things more. If something went wrong (and that's what happens if this one is called), you don't actually want the application to grab the signal and exit gracefully because that's probably the whole reason why this function was called in the first place - it will just hang. It should die. So I'd suggest maintaining SIGTERM, but using kill(pid, 9) instead of kill(0, 9). Patch committed to CVS. Ronald -- Ronald Bultje <[EMAIL PROTECTED]> Linux Video/Multimedia developer ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Mjpeg-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mjpeg-users
