> But that's more working around the problems than fixing them, no? I don't think Unix signal behavior is the problem. The problems outlined in the article st

> But that's more working around the problems than fixing them, no? I don't think Unix signal behavior is the problem. The problems outlined in the article stem from people using them inappropriately. The new signal syscalls introduced in Linux over the years haven't stopped people from misusing them. > You can't really move all signal handling logic to a dedicated process, because every process can receive signals. Processes are not obliged to take action in response to signals. But, they could simply propagate the signal data to the parent process via a pipe file descriptor it inherits. Then, you could place all the signal-handling logic into a supervisor -- the supervisor would get notified via a pipe when one of its descendants receives a signal, and take appropriate action. > And as for databases: every major production database I've seen implements its own authentication and permission scheme, so it can do things like provide ACLs on a more granular (per-table, sometimes per-row) basis. No one said an application can't have its own authentication and permission scheme. All I am saying is that if you factor your application into multiple processes running under different system-level user accounts, you can get more mileage out of the Unix permission system than you could otherwise, because the kernel would be able to distinguish individual pieces of your application as having different sets of permissions.