[dmd-concurrency] shutting down

[Steve Schveighoffer]

----- Original Message ----
> From: Andrei Alexandrescu <andrei at erdani.com>
> To: Discuss the concurrency model(s) for D <dmd-concurrency at puremagic.com>
> Sent: Wed, January 20, 2010 4:00:22 PM
> Subject: Re: [dmd-concurrency] shutting down
> 
> Michel Fortin wrote:
> > Le 2010-01-20 à 15:24, Andrei Alexandrescu a écrit :
> > 
> >> I think threads shouldn't be able to do much during shutdown. For example I 
> don't think they should suddenly open sockets. How about opening files? Or 
> calling system()? Any ideas on a unified approach?
> > 
> > Why do you think that?
> 
> 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 sockets library do today is, they offer a global close_library function. 
> Once that is called, all pending socket connections and all new socket 
> connections fail immediately.

You're getting closer to a function that effectively and artificially kills all threads.  I don't really like this scenario, a thread should be able to do whatever it wants, even during shutdown.  For instance, let's say you log that a thread is ending via a finally clause at the end of the thread.  This works no problem with default logging configuration since the log is to disk, but one enterprising user has all his applications log to a network socket, so he configures the logging library of your app to use a network socket to store data.  All of a sudden, the logs go away because doing the log causes an exception.  I think this is unacceptable and hard to plan for.  You can't possibly know all the uses of sockets in underlying functions that a thread may call on shutdown.  I think all those should be allowed to proceed.

Not to mention you are relying on the network library providing such a function which might not exist (killing all socket communication is not a standard socket function).  Someone who wants this behavior can implement it manually in environments where it is provided -- I don't think it should be a standard practice.

Normal practice is to not block on a socket indefinitely (i.e. wait for data in a loop with a timeout, checking for shutdown every loop), or wait for both socket data *and* another event.  In some OSes, the latter is not possible, and I think Phobos should try to use the least common denominator.

On the other hand, it's perfectly valid to compose such a loop in a standard function without relying on OS ability:

ubyte[] readWithShutdown(Socket s, int period, int timeout, ubyte[] buffer);

what this means is, read from socket s in a loop, checking for shutdown every period, returning with no data after timeout elapses.  Increasing the period improves CPU usage, but makes shutdowns less responsive.

I'd prefer such an approach to infiltrating the socket library using assumptions that might not be true.

BTW, I agree that all threads should exit when main exits.  Any multithreadded app I've written always follows this rule.  I haven't ever really had a need to use a daemon thread.

-Steve