[dmd-concurrency] Shutdown protocol

[Andrei Alexandrescu]

Steve Schveighoffer wrote:
> ----- Original Message ----
> 
>> From: Andrei Alexandrescu <andrei at erdani.com>
>>
>> I worked for three Internet companies during 1997 and then 1999-2001. As fate 
>> has it, I never got to directly write low-level networking code. But I worked on 
>> and managed projects involving threads and network connections, and worked 
>> closely with experts in socket-based networking. I can say I know (or knew at a 
>> point) RealDownload as well as I had written it myself. Incidentally I have 
>> intimate knowledge regarding shutting sockets down because I was involved in the 
>> threading part of such programs so figuring out orderly shutdown was a 
>> challenge. I'm not counterspeculating here.
> 
> This is not 1999 or 2001.  I'm sure MFC was heavily used in those projects also :)

I agree. I seem to recall back in those times libraries were a lot less 
reliable and more poorly documented. I just browsed a few now and they 
are much clearer about what they do. InternetCloseHandler() was an utter 
mistery in 1997 when it appeared.

>> One thing is for sure: everybody I know in networking and their sister close the 
>> library and let sockets fail when shutting the application down.
> 
> I only know what I've developed in my projects, and the most effective and robust shutdown I found involved properly cleaning up sockets.  Having a shutdown time of a few seconds is not terrible, and allows proper cleanup.  I've never had any problems in my applications of having blocking sockets hold up shutdown, because I always write my threads to periodically check for shutdown.

That's the difference between a hard shutdown and a graceful shutdown. I 
think application exiting always does a hard shutdown in all programs 
I'm using starting with wget and ending with Firefox and Opera.

Note that it's not about a few seconds: socket streams are obstinate as 
a mule. They'll wait for 60-90 seconds to terminate if the connection is 
infinitely slow.

>> I think it's tenuous to conceive an application that doesn't terminate when the 
>> user wants to terminate it. Even MS Money, which synchronizes online when you 
>> shut down (a weird design if you ask me) has a "Exit now" button that does what 
>> needs to be done.
> 
> It happens all the time.  Even on my Linux laptop I occasionally have to kill a process from the command line because it doesn't exit.  What you want is to hard-wire the "close application" button of the window manager to killing all sockets.  That's no good.  An application should be free to do whatever it wishes when the user wants it to close (save files, flush network data, etc).

I agree that e.g. Firefox is a large beast that hangs. What I'm saying 
is that it uses hard shutdown on its sockets. Otherwise it would 
_always_ take 60 seconds to close in an airport.

>> If you exit main, there is no waiting for sockets.
> 
> I have no problem with main calling exit() to finish the application after D's main exits.  Kill everything at that point.  But a builtin shutdown facility is not equated to exiting main in my opinion.

The way I see it is very simple: you have ample opportunity to do 
whatever you deem appropriate for as long as main() runs. After that, 
it's in the hand of the system, and the system is not responsible for 
giving quarters to unsaved data, unclosed sockets etc.

No mercy.


Andrei