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
