On 14.09.2006, at 21:46, Stephen Deasey wrote:
What are your rules for checking for a long running process?
If the ns_proxy command is for isolating badly behaved code, it seems
to me there could usefully be a few more built in checks for bad
behaviour, rather than having to implement these checks manually.
True.
For example, how about a switch which defines the maximum running time
for the command? You can handle this now as Zoran points out by
waiting for the result with a timeout. But this is awkward to handle
if you have a 'detached' proxy job.
This can be done "indirectly":
set milliseconds 2000
set p [ns_proxy send $p some_broken_hanging_script]
if {[catch {ns_proxy wait $p $milliseconds}]} {
ns_proxy put $p
}
Put it in a procedure and there you go.
Explicitly passing the runtime-timeout would also eliminate some race
conditions. Let's say you start a job, then in some other thread get a
list of jobs including pid, figure out a job has taken too long, then
kill the pid. The job could exit between the time you get the pid and
the time your decide to kill it. Pid's recycle (eventualy), and you
kill some completely unrelated proces.
Heh... bad cruel world... but it isnt really that black really.
Normally the pid wrapup should take some time...
Runtime limits could be implemented with a timer and signal handler in
the proxy process.
Or as above.
One common bad behaviour other than lack of thread safety is memory
leaks. How about some switches which set rlimits for the process,
maximum heap memory and such? This would also be a nice safety
feature -- say you're converting images or movies uploaded by some
untrusted source and you want to ensure a flaw in your converter
library doesn't compromise your server.
Maybe a chroot switch would be useful?
Yes! All this could be really useful. The only trouble is
the syntax. How to pass this to the new process?
Over the cmd line? Env array? Store this per pool (most probably)?
