[dmd-concurrency] shutting down

[Sean Kelly]

On Jan 21, 2010, at 10:15 AM, Andrei Alexandrescu 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.

It can be a challenge in large asynchronous servers, but for the most part it isn't too terrible.  Generally, you end up setting a flag, closing the sockets, and then tearing down the rest.  An even more structured approach is to signal the wait queue and let it unwind itself, which is sometimes necessary depending on how unexpected close events percolate through the system.

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

Seriously?  Is this in server or client apps?  In server apps an orderly shutdown is generally crucial, since data often has to be serialized, logging must be done, etc.  Knocking a few support beams out in the basement and then running for cover has never been considered good engineering in my book :-)  I know that I've personally never used this approach, even in Windows where it's ostensibly possible.  If it's relevant, I can provide an asynchronous networking library and a few server apps I wrote in the 90s as examples.

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

Servers and services generally work this way.  In fact there often isn't a main() function at all, since it's common to build them as shared libraries (Windows NT Services, for example).  An event is triggered when a shutdown is desired, and the signal must propagate through the system.  In this case it might be possible to designate some main execution loop as the main thread, but I'm frankly skeptical that a clean shutdown could be handled magically via the method previously described.

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

Why?  Even electronics these days generally don't have an on/off switch that's hardwired to the power supply.  Instead they send a signal that's received by the system and processed in an orderly manner.  I still have to unplug my laptop and pull the battery to shut it down on occasion when it gets wedged in some particularly interesting manner.