71–76 of 76 posts
> Another common extension is to use what is sometimes called a double Ctrl-C pattern. The first time the user hits Ctrl-C, you attempt to shut down the database cleanly, but the second time you encounter it, you give up and exit immediately. This is a terrible behavior, because users tend to hit Ctrl-C multiple times without intending anything different than on a single hit (not to mention bouncing key mechanics and…
The article doesn't mention the most useful of all signals: SIGINFO, aka "please print to stderr your current status". Very useful for tools like dd and tar. Probably because Linux doesn't implement it. Worst mistake Linus ever made. Also, it talks about self-pipe but doesn't mention that self- socket is much better since you can't select on a pipe.
For most users in the real world, self-pipes are sufficient. This includes mio (Tokio's underlying library)'s portable Unix implementation of wakers (how parts of the system tell other parts to wake up).
The article doesn't mention the most useful of all signals: SIGINFO, aka "please print to stderr your current status". Very useful for tools like dd and tar. Probably because Linux doesn't implement it. Worst mistake Linus ever made. Also, it talks about self-pipe but doesn't mention that self- socket is much better since you can't select on a pipe.
SIGSTOP and SIGCONT are very useful as well. SIGSTOP is the equivalent of Ctrl-Z in a shell, but you can address it to any process. If you have a server being bogged down, you can stop the offending process temporarily. SIGCONT undoes SIGSTOP. The cpulimit tool does this in an automated way so that a process can be limited to use x% of CPU. Nice/renice doesn't keep your CPU from hitting 100% even with an idle priorit…
I have a very exciting blog post about debugging a nasty bug with how SIGTSTP works, coming very soon.
Earlier quoted context omitted.
It's worse, because there are languages that encode interruption into the error handling functionality, so it's common that people mismanage their errors and programs require several Ctrl-C presses to actually reach the interruption handler. What means that you have to memorize a list of "oh, this program needs Ctrl-C 3 times; oh, this program must only receive Ctrl-C once!"... I don't know of any "oh, this program n…
Any software I've come across that uses intentional double ctrl-c shows a message after the first ctrl-c. Something to the effect of "shutting down gracefully, press ctrl-c again for immediate shutdown". Hence you can just press it once and wait half a second, if no message to this effect appears you can spam ctrl-c.
Earlier quoted context omitted.
Disagree. Annoyingly there is a reasonable case for 200 but with an error, if http is your transport but not your application, then 200 says "yes, the message was transfered and understood correctly, here is your response" which may be an error response from the application
If you’re using HTTP for something other than transferring hypertext — i.e., if your application is not a hypermedia application — then you are doing something just as wrong as encoding IP in DNS packets or email messages. Don’t do that. It’s wrong, even if it is technically interesting. If, OTOH, your application is a hypermedia application, then returning a success status for errors is just wrong.
Earlier quoted context omitted.
> Turns out, they use SIGWINCH (which is sent on WINdow CHange) for graceful shutdown. That’s … that’s even worse than people who send errors with an HTTP 200 response code.
That's ... not what most people are doing. People send _application_ errors on HTTP 200 response codes, because HTTP response codes are for HTTP and not applications. Most "REST" libraries and webdev get this wrong, building ever more fragile web services.
For example, HTTP 409 Conflict generally means an application-level conflict (e.g. an optimistic concurrency mechanism detected a conflict).
HTTP 422 Unprocessable Entity is also usually an application-level error (e.g. hash validation failure, or identifier not recognized by the server).