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
--