Keeping an eye on hung system calls..
tjc at wintrmute.net
Tue Jun 6 11:14:06 BST 2006
I have a little app to make jpeg thumbnails out of video files. It's nothing
special, it just spawns mplayer to get a jpeg out of the first frame..
However I have a problem with mplayer occaisionally getting hung on some files
it can't handle well, and never exitting.
So, this lead me to wonder about methods of keeping an eye on system() calls.
Two methods we've thought of so far:
1) fork() prior to calling system() (or exec()), and then call alarm() before
waiting for the child to finish, or killing it from the alarm sighandler.
2) Use ithreaded Perl, and spawn a new thread to handle the system() call.
The other thread simply waits for the timeout, and then checks to see if the
other thread has exitted.. if not, *bang*.
(A third option would be to write an XS module that directly links the mplayer
libraries, but that isn't trivial.)
Both methods are kind of ugly though.. The system() call is expensive enough as
it is (including it's own fork&exec), and I'd still need to find a mechanism to
make sure I can kill the system-child of the worker fork-or-thread, as well as
just the worker.
I was wondering.. perhaps this conundrum has already been solved? Or am I just
going in totally the wrong direction?
Turning and turning in the widening gyre/The falcon cannot hear the falconer;
Things fall apart, the centre cannot hold/Mere anarchy is loosed upon the world
(gpg --keyserver www.co.uk.pgp.net --recv-key B1CCF88E)
More information about the london.pm