[dmd-concurrency] Shutdown protocol

[Steve Schveighoffer]

----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> 
> 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.

This facility is http and ftp specific, and only works if you use Windows' WinInet library:

"The Microsoft Windows Internet (WinINet) application programming
interface (API) enables applications to access standard Internet
protocols, such as FTP and HTTP. For ease of use, WinINet abstracts
these protocols into a high-level interface."

All sockets can be cleaned up with WSACleanup:

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

Which appears to do what you want -- except if you are calling it from DllMain:

"The WSACleanup function typically leads to protocol-specific helper DLLs being unloaded. As a result, the WSACleanup function should not be called from the
DllMain function in a application DLL. This can potentially cause
deadlocks. For more information, please see the DLL Main Function."

I don't think we should use this.

-Steve