June 14th, 2010
I cannot think of a utility in *nix that you can use to run a program for a specified time. That is, to run an mplayer stream for a minute and then kill it.
So I wrote one.
a simple wrapping perl script would do as well.
It would, but you'd have to be careful with quoting. Once you get past that slight challenge, it's going to do the exact same thing as this program, but with the overhead of an interpreter.
I can't imagine why you'd want to modify it once it's finished.
One might be able to make it smaller in a different language? As it is, it's 76 lines of straightforward code and 13 of them are because I found out that signal() is deprecated and the over-engineered and under-documented sigaction() is it's replacement. And I'm counting the blank lines for readability in those 76.
(By the way, when I say "under-documented", I mean that I actually filed two separate bugs against the documentation and had to look at someone else's code to work out what the man page had left out.)
So what on Earth is the reason for using perl here?
EDIT: Maybe one could have written it faster in perl? But apart from the 30 minutes or so I spent trying to make sense of sigaction(), the code took me 10 minutes to write and test. Ample time for me to use it and dress it up a bit for release, actually.
Edited at 2010-06-15 11:00 am (UTC)
|Date:||June 15th, 2010 07:36 pm (UTC)|| |
I believe that the ulimit command can be used to do the same thing. There is a "max CPU time allowed" option. For something CPU-intensive like mplayer, it's equivalent.
mplayer is also I/O intensive -- it has to read those media files and write to devices -- and that I/O time causes it to spend a lot of time in a waiting state where it does not accumulate CPU time.
In the course of playing around three seconds of a FLAC just now, mplayer accumulated about half a second of CPU time.
In any event, CPU time and wall time are very rarely equivalent which limits the feasability of using ulimit. Never mind that the relationship between the two is also affected by how busy the system is at the time.
|Date:||June 15th, 2010 11:38 pm (UTC)|| |
True. The I/O wait time will detract from the utility of using ulimit that way.
A feature that would be nice to have in ulimit is a 'max time to exist in the process table' option.
Yeah -- it would be the most likely candidate for this functionality. Sadly, there's two reasons it's not likely to happen. For one, bash implements its own internal version of it. Secondly, its options are specified by POSIX.
Something else I've done...
mplayer foo &