[dmd-concurrency] shutting down

Kevin Bealer kevinbealer at gmail.com
Wed Jan 20 20:16:58 PST 2010


On Wed, Jan 20, 2010 at 8:50 PM, Andrei Alexandrescu <andrei at erdani.com>wrote:

> Michel Fortin wrote:
>
>> Le 2010-01-20 à 18:37, Andrei Alexandrescu a écrit :
>>
>>  Sean Kelly wrote:
>>>
>>>> On Jan 20, 2010, at 1:00 PM, Andrei Alexandrescu wrote:
>>>>
>>>>> I'm thinking, there are too many programs that hang when I want to end
>>>>> them just because some thread inside is waiting for a socket. I think that
>>>>> any operation that could block for an arbitrary amount of time should be
>>>>> disallowed during shutdown.
>>>>>
>>>> What if the program is logging to a remote host and wants to log a
>>>> shutdown event?
>>>>
>>> I think it should do so in main. Nevertheless, my intuition is that we
>>> can use a judgment call a la "file operations are considered fast so we
>>> won't kill them" even though technically a file could be opened over a
>>> network connection.
>>>
>>
>> This is the kind of assumption I'd gladly do without.
>>
>> While typically you might consider the network slow, there are cases where
>> the software is designed to work with some specific hardware. When you have
>> a guarantied 1000 Mbps Ethernet crossover wire connecting directly two
>> devices, you know the network interface isn't slow. In fact, the latency is
>> probably much better on an 1000 Mbps Ethernet link than with a rotating hard
>> drive.
>>
>> Also if you're writing a program that works on one of these two
>> interdependent devices, sending a shutdown notice to the other system is one
>> thing you definitely want to do.
>>
>> This is not a made-up example.
>>
>
> I agree, but the disk is usually encased with the machine. The network is a
> connection with an independent machine. That's a fundamental difference. I'm
> aware that many things that seem to be disks and files are also really
> connections with independent machines.
>
> Nevertheless, I'm open to any idea that makes things better. In short
> nobody stops people in special situations from writing code that does the
> appropriate synchronization. I just want to figure out some reasonable
> defaults, and to me it seems like taking down sockets but not files is a
> reasonable default. Do you know a better one?
>
>
> Andrei


I think it's bad to have a special shutdown mode that everyone has to use
for their primary shutdown approach.  But I think the good news is, this
isn't necessarily a "make everyone do X" scenario.  Assuming the OOB exposes
enough power to allow users to do most of this themselves, then it's a
matter of having a selection of policies and letting people pick one off the
shelf or (in special cases) send their own messages of doom.

I want a way to send messages to all actors and in general to implement my
own scheme for this kind of policy.  If I can do my own all-points-bulletin
with tools that are just as powerful as what your version is using, then I
can just do whatever I want from main() and let your end-of-main code be
plan B.  In that case, I love your plan because it's a reasonable default
for people who don't have specific requirements and for most smallish
applications.

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/dmd-concurrency/attachments/20100120/9dd461c0/attachment-0001.htm>


More information about the dmd-concurrency mailing list