[dmd-concurrency] Shutdown protocol

[Andrei Alexandrescu]

Sean Kelly wrote:
> On Jan 21, 2010, at 12:14 AM, Andrei Alexandrescu wrote:
> 
>> Kevin Bealer wrote:
>>
>>> So lets say that threads will normally fall into the three camps, that I'll call producers, filters and processors.
>> [snip]
>>> Main could check if it has any dependents, if desired... (these last bits is kind of off the cuff, so maybe there are huge problems with them.)
>> This makes sense, but at this point I'd avoid classifications that don't have a precedent. If Erlang made it without thread kinds, we should too.
> 
> To be fair, Erlang also doesn't have this shutdown behavior.

There are two precedents for the proposed shutdown behavior. One is the 
behavior of sockets in both Unix and Windows networking library. The 
libraries have one entry point for shutting down the entire library, 
after which all pending or new calls fail immediately. For example, 
quoting from

http://msdn.microsoft.com/en-us/library/aa384350%28VS.85%29.aspx

"The function terminates any pending operations on the handle and 
discards any outstanding data. If a thread is blocking a call to 
Wininet.dll, another thread in the application can call 
InternetCloseHandle on the Internet handle being used by the first 
thread to cancel the operation and unblock the first thread."

This is why you can close a browser instantly even though there may be a 
dozen pages still waiting to load.

The second is Java's experiment ThreadDeath:

http://java.sun.com/j2se/1.4.2/docs/api/java/lang/ThreadDeath.html

That experiment failed because they couldn't find a reliable method for 
transforming the exception from aysnchronous to synchronous.

My idea combines these two.


Andrei