You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now the fork function accepts a 'timeout' option, and after that long has elapsed it will send a SIGKILL to the child.
Two approaches would be better.
We could use a SIGTERM -> SIGKILL chain to allow well-behaved programs to terminate cleanly (ruby processes would typically raise a signal error, which would propagate back out to the parent, but even ffi code can clean up from a SIGTERM). The main drawback is the amount of race-condition and timing code that would need to be written and tested.
We could allow the user to supply the signal type, so that the parent will send whatever signal is specified. This is pretty easy, and gets us most of the power, but without guaranteeing termination.
We could reasonably combine the two by allowing a set of timeouts and signals to be supplied, like { kill: 100, hup: 58 }, and manage all of the timeouts. Then we could interpret timeout: 10 to mean timeout: { kill: 11, term: 10 }.
The text was updated successfully, but these errors were encountered:
Right now the
fork
function accepts a 'timeout' option, and after that long has elapsed it will send a SIGKILL to the child.Two approaches would be better.
We could reasonably combine the two by allowing a set of timeouts and signals to be supplied, like
{ kill: 100, hup: 58 }
, and manage all of the timeouts. Then we could interprettimeout: 10
to meantimeout: { kill: 11, term: 10 }
.The text was updated successfully, but these errors were encountered: