The overhead here is in the directory scan, not the sleep (which has almost no overhead). So the first priority would be to make sure that the directory is kept as empty as possible, so that each iteration didn't have to scan over files that had previously been seen. Scanning a directory is pretty efficient too, as long as we're only looking at information that is in the directory inode. So if your scheme involves moving the file out of the directory once it has been processed, then I wouldn't worry too much about it, and you could probably set the sleep time to somewhere between 0.1 and 0.5 seconds without any noticeable overhead. But if the directory is going to accumulate thousands of files, that's another story.
The only way to make it more efficient would be to have the background process wait on some kind of signal, or maybe a TCP message, rather than repeating the directory scan every unit of sleep time. For example, you could have it sleep in a loop until it gets a signal, the simplest of which would be SIGINT (via
MX_KILL or just KILL.LIT) causing it to jump the error trap routine ...
on error goto TRAP
WAIT:
? "Waiting...";tab(-1,254);
do
sleep 10
? ".";tab(-1,254);
loop
? "Fell out of loop"
end
SCAN'DIRECTORY:
? "Scanning directory for new files..."
! <processing here>
goto WAIT
TRAP:
? "Error ";err(0)
if err(0)=1 then
resume SCAN'DIRECTORY
else
? "Aborting"
end
endif
In that case you'd need another signal, perhaps -TERM, to actually terminate it.
Setting the nice and/or ionice values presumably can't hurt. I think you can use renice on your own process (via XCALL HOSTEX), so that would be the simplest add-on. The other two would require changing the way you launch the process from AMOS to HOSTEX, but that's easy enough too. Again, I don't think there is much CPU overhead in your scheme (unless the directory contains a lot of files), so probably the ionice would be the more significant one. But I bet you'll have a hard time measuring it, since we're probably only talking about a one block read, which most of the time will already have been cached.
It might be interesting to try using
RUNPROF on the program to see if you can measure any appreciable CPU time. (It doesn't have a provision to help you measure how much I/O overhead it's causing though.)
