<div class="gmail_quote">On Wed, Jan 20, 2010 at 8:50 PM, Andrei Alexandrescu <span dir="ltr">&lt;<a href="mailto:andrei@erdani.com">andrei@erdani.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">Michel Fortin wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Le 2010-01-20 à 18:37, Andrei Alexandrescu a écrit :<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Sean Kelly wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Jan 20, 2010, at 1:00 PM, Andrei Alexandrescu wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I&#39;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.<br>

</blockquote>
What if the program is logging to a remote host and wants to log a shutdown event?<br>
</blockquote>
I think it should do so in main. Nevertheless, my intuition is that we can use a judgment call a la &quot;file operations are considered fast so we won&#39;t kill them&quot; even though technically a file could be opened over a network connection.<br>

</blockquote>
<br>
This is the kind of assumption I&#39;d gladly do without.<br>
<br>
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&#39;t slow. In fact, the latency is probably much better on an 1000 Mbps Ethernet link than with a rotating hard drive.<br>

<br>
Also if you&#39;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.<br>
<br>
This is not a made-up example.<br>
</blockquote>
<br></div>
I agree, but the disk is usually encased with the machine. The network is a connection with an independent machine. That&#39;s a fundamental difference. I&#39;m aware that many things that seem to be disks and files are also really connections with independent machines.<br>

<br>
Nevertheless, I&#39;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?<br>
<font color="#888888">
<br>
<br>
Andrei</font></blockquote><div><br>I think it&#39;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&#39;t necessarily a &quot;make everyone do X&quot; scenario.  Assuming the OOB exposes enough power to allow users to do most of this themselves, then it&#39;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.<br>
<br>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&#39;s a reasonable default for people who don&#39;t have specific requirements and for most smallish applications.<br>
<br>Kevin<br><br></div></div>