On Wed, 9 Oct 2002, Larry Osterman wrote: >Arnt, I'm not trying to be confrontative (really, I'm not), but I'm >wondering if this is starting to devolve into a djb-style "should your >SMTP client send quit before closing the connection" argument? >I'm starting to have a serious case of deja-vu.... >Larry Osterman
I think DjB has a pretty ok answer here. Send the QUIT, but waiting for the SMTP service's response is pointless. Andy >-----Original Message----- >From: Lyndon Nerenberg [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, October 09, 2002 2:59 PM >To: Arnt Gulbrandsen >Cc: [EMAIL PROTECTED] >Subject: Re: to logout or not... > > > Arnt> 1. The user closes the MUA's window. > >Closing the window does not have to equate with application termination. >Or did you really mean to say "the user terminates the application?" In >either case, the application has to perform whatever cleanup steps are >appropriate before letting the process terminate. Sometimes this can >take more than a few milliseconds, byt in a GUI enviorment, this >processing can happen "behind the scenes" as far as the GUI user is >concerned, so I don't see this scenario being a problem. > > Arnt> 2. The user logs out, and the session manager tells > Arnt> applications to save their state and exit quickly. > >"Quickly?" Session managers tell applications to save state and exit. >They also give the applications a reasonable amount of time to do so. >When I implement session management code, I set the "forced kill" timer >to something very high (at least a minute, usually). Almost always, the >applications will clean up and exit almost immediately. But in the case >where they don't, there's usually a good reason for it. For example, the >client system might be under high load, and needs some time to acquire >the resources necessary to shut down (e.g. the system is swapping, and >the kernel needs a couple of seconds to push something else out in order >to bring the application into memory, all while all the other >applications are trying to do the same thing). In a high load situation >like this, the *last* thing you want is a session manager blindly >assuming it know better than everyone else. > >In a GUI environment, you can pop up a status window telling the user to >sit tight for a minute while the session closes. > > Arnt> 3. The application is told that the machine will suspend in > Arnt> 0.1 seconds (a laptop, typically). > >So what? Just leave the network connection alone. TCP connections last >forever. When the laptop comes back it 1) just keep using the existing >connections, 2) will see an IDLE timeout from the server and close the >connection, or 3) will have a new IP address, causing the existing >connections to reset. None of these cases need special handling in an >IMAP client. (For case (3), the server will timeout after 30 minutes and >close it's side of the connection.) > > Arnt> 4. The application runs on unix and receives e.g. SIGINT. > >signal(SIGINT, handler_func); > > Arnt> Sorry, no can do. > >Then you have a very exceptional environment that you are running in. >(Or just have no patience whatsoever.) > >I really think you're inventing a problem that doesn't exist. If the >client needs to shut down, it should just do a normal shutdown. It >can't control what the OS does in this regard, and should not waste any >time trying to second guess things it has no control over to begin with. > >--lyndon > -- Andreas Aardal Hanssen
