On 29/10/2015 16:01, David Holland wrote:
Hardly; it moves the burden of doing stupid things to the application. If as you said the goal is to shut down all threads cleanly, then it doesn't need to keep track in detail anyway; it can just post SIGTERM to every thread, or SIGUSR1 if SIGTERM is bad for some reason, or whatever.
I agree that the root issue is poor application design, but posting a signal to every thread is not a solution if you only want to shut down a subset of threads.
close(2) as specified by POSIX doesn't prohibit this weird revoke-like behavior, but there's nothing in there that mandates it either. (I thought this discussion had already clarified that.)
There was an attempt to interpret POSIX that way, with which I still disagree. If a FD is closed or reassigned then any current pending operations on it should be terminated.
Note that while NetBSD apparently supports this behavior because someone copied it from Solaris, I'm about to go recommend it be removed.
Which behaviour? The abort accept() on close() behaviour? -- Alan Burlison -- -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
