On Mon, Jun 19, 2000 at 05:40:30PM -0700, Mike Smith wrote:
> The real issue here is persistent system state across the S4 suspend; ie.
> leaving applications open, etc. IMO this isn't really something worth a
> lot of effort to us, and it has a lot of additional complications for a
> "server-class" operating system in that you have to worry about network
> connections from other systems, not just _to_ other systems.
Don't the normal TCP timeouts take care of existing connections?
I doubt that a "server class" system will be going into suspend
mode for any reason, but I would imagine that suspend/resume
should look much like network outage for the clients of
suspended servers.
For the only place that I can see it mattering (laptops), I
suspect that suspend/resume should be an X session manager and
application level job, and the kernel should just shutdown
and boot as normal. I know that there aren't too many X
applications that do all of the session management things, but
maybe that would change if suspend actions interacted with the
popular desktops in the appropriate way.
--
Andrew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
