spencer@eris.UUCP (09/17/87)
In article <81@ur-tut.UUCP> (Davide P. Cervone) writes: > >I have a concern that doesn't seem to have been addressed yet in the "kill >any process" suggestions. Basically he says "If all we do is free up the memory of a killed process, what happens to: Memory that has been sent to another process as a message, Other process that allocate memory because of the killed process: Windows that I opened The space the screen open in its list The LayerInfo structure Also processes could be locked and never exit: The console process that talks to my window The serial device, which would never let others use it > >In an environment where process share their resources in so many ways, I >really worry about cleaning up after a process without some knowledge of what >that process was doing. I hope someone finds a way to do it, though. > >Davide P. Cervone Now, I can understand why so many programmers are talking about an Exec that tracks resources, since it would save so much programming time, but as David points out, I don't think that there is alot that can be done about it at this point. Especially with Commodore not wanting to mess with already developed software, and with a developer base that has only recently stopped complaining about an OS that is changing on them all the time. Where I think all this discussion could lead is into how to re-write the OS to support an MMU on the 2000 (we do have an MMU slot you know). We already have problems with the OS, in that the whole message-passing environment *relys* on everybody getting to everything. Since it does rely on it, there will have to be some sort of re-write when the MMU board is released. So, what do we need to do to get the OS to work in a protected memory environment? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)284-4740 I N F I N I T Y BBS: (415)283-5469 Now working for |||||||||||::::... . . BUD-LINX But in no way |||||||||||||||::::.. .. . Officially representing ||||||||||||:::::... .. ....ucbvax!mica!spencer s o f t w a r e spencer@mica.berkeley.edu -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
peter@sugar.UUCP (Peter da Silva) (09/21/87)
> [what do we do to get the O/S to work in a protected memory environment]
There's already a hook for that. It's called MEMF_PUBLIC. If you specify
MEMF_PUBLIC in a call, you'll get memory in the common pool. If you don't,
you'll get memory attached to your local shuffle-able address space. Probably
MEMF_CHIP would get locked on the grounds that the hardware needs to get at it,
which might make it hard to make it private (due to granularity of the MMU).
Ideally, each task would see their PRIVATE memory always growing from the end of
CHIP, with PUBLIC memory mapped in up somewhere near the I/O page (or down in
CHIP if that's what it is). Alternatively, PRIVATE memory could be mapped to
start at the end of 68000 memory (if it's a 68020 version, right... 68000s
would still have to stay under 16 meg).
--
-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter
-- 'U` Have you hugged your wolf today?