On Sep 16, 7:47am, Robert Elz wrote:
}
} I used to program such things in the past (distant past) - one of the
} requirements of the particular system I was using was that processes
} were not allowed to run for "too long" before calling the system process
} switch function (no kernel running clock interrupts to do time slicing).
That was Windows for a very long time, i.e. co-operative
multi-tasking. I wrote one Windows app in the Windows 3.1/95 era.
I hated it. Terrible programming environment. Heck, all of Windows
would stop running when you ran the application under a debugger.
At least I figured out a dual monitor setup (Windows running on a
VGA adapter and the debugger running on a Hercules adapter).
} | In cases where it _is_ expensive, or at least where it's expensive to
} | figure out, the same argument applies as against garbage collection:
} | if you aren't sure what the lifetime of that object is, and the
} | program isn't structured in a way that allows being reasomably sure it
} | is disposed of exactly once, how can you have confidence in any other
} | correctness properties?
}
} That isn't the issue at all - in the programs in question, there's no
} issue with the lifetimes of objects, it is from creation until something
} explicitly makes them go away, or process exit, whichever comes first.
Process exit does it much more efficiently as well. Instead
of trying to find every object and free memory a few bytes at a
time, the entire address space is freed in fell swoop.
}-- End of excerpt from Robert Elz
