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
Some systems distinguish between a graceful shutdown and a forceful termination. This distinction cannot be delivered through AbortController. It would be nice if the same channel could be used to deliver both.
The current interface might extend to this cleanly, without breaking anything. The delivered Event could provide a boolean .force indicating whether a forceful abort was requested or not. AbortController.prototype.abort() could take the option { force: true } to request a forceful abort. A second call to abort() could be allowed, for requesting forceful abort after a standard abort was already requested.
2 levels of strength seem sufficient. I've never seen a use for further distinctions.
Some usage patterns.
Request forceful abort immediately. Everything is terminated as quickly as possible.
This might be tied to a more forceful user control, eg Kill vs Cancel.
Request standard abort with a time limit. Request forceful abort if it times out.
This might be useful where closing a connection can take a long time. The close logic can have retries to tolerate transient network errors, with delays between them. If the process drags on too long, terminate.
process.on('SIGINT',()=>{// Await close of everything watching the signalPromise.allSettled(clients.map(client=>client.done)).then(()=>{process.exit()})// Request standard shutdowncontroller.abort()// Time out standard shutdown in 5 seconds// Unref the timer to prevent it keeping the process aliveconsttimer=setTimeout(()=>{constreason=newError('Closing connection timed out')controller.abort(reason,{force: true})},5000)timer.unref()})
Offer users 2 levels of interrupt.
This is a common pattern in the CLI interface of servers. The first CTRL+C initiates a graceful shutdown: the server stops accepting new connections and waits for existing connections to complete normally. A second CTRL+C during graceful shutdown terminates all open connections without waiting for completion and shuts down immediately.
$ ./server
Serving 112 requests
Interrupt received, shutting down
Completed 52/112 requests
Second interrupt received, terminating open connections
letshuttingDown=falseprocess.on('SIGINT',()=>{if(!shuttingDown){// First interrupt, start graceful shutdownshuttingDown=trueprogram.closed.then(()=>{process.exit()})controller.abort()}else{// Second interrupt, kill everything nowcontroller.abort(undefined,{force: true})}})
The text was updated successfully, but these errors were encountered:
Some systems distinguish between a graceful shutdown and a forceful termination. This distinction cannot be delivered through
AbortController
. It would be nice if the same channel could be used to deliver both.The current interface might extend to this cleanly, without breaking anything. The delivered
Event
could provide a boolean.force
indicating whether a forceful abort was requested or not.AbortController.prototype.abort()
could take the option{ force: true }
to request a forceful abort. A second call toabort()
could be allowed, for requesting forceful abort after a standard abort was already requested.2 levels of strength seem sufficient. I've never seen a use for further distinctions.
Some usage patterns.
This might be tied to a more forceful user control, eg Kill vs Cancel.
This might be useful where closing a connection can take a long time. The close logic can have retries to tolerate transient network errors, with delays between them. If the process drags on too long, terminate.
This is a common pattern in the CLI interface of servers. The first CTRL+C initiates a graceful shutdown: the server stops accepting new connections and waits for existing connections to complete normally. A second CTRL+C during graceful shutdown terminates all open connections without waiting for completion and shuts down immediately.
The text was updated successfully, but these errors were encountered: