Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!agate!shelby!msi.umn.edu!noc.MR.NET!gacvx2.gac.edu!scott From: scott@next-5.gac.edu (Scott Hess) Newsgroups: comp.sys.next Subject: Re: memory (was: slab vs. cube and $$) Message-ID: Date: 1 Dec 90 21:38:55 GMT References: <12081@life.ai.mit.edu> <1990Nov29.161041.15775@magnus.ircc.ohio-state.edu> <1990Nov30.013031.25032@mp.cs.niu.edu> <12108@life.ai.mit.edu> <4326@amc-gw.amc.com> Organization: Gustavus Adolphus College Lines: 36 Nntp-Posting-Host: next-5.gac.edu In-reply-to: kenb@amc-gw.amc.com's message of 1 Dec 90 06:55:48 GMTLines: 36 In article <4326@amc-gw.amc.com> kenb@amc-gw.amc.com (Ken Birdwell) writes: >I suppose that the process that got the parity error could get a SIGBUS >error. I'm sorry but it's really dangerous to keep running after that sort >of thing happens. On most UNIX system you'll get a 'panic: parity error' >with no idea of where and the system will shut itself off. Now this is alot >better then doing stuff like, spewing to a now random file handle or jumping >into a function that formats your hard disk or at a minimun trashes all your >saved data because some comparison failed or whatever but I agree, powering >down is nasty. I think that killing the process (if possible; if parity >error occured in the schedular, youre screwed) is a resonable thing to do. >Its kinds nice to not let your program go into Lala-land without telling you. >Just think of it as a random SEGV, and I know of no-one who thinks it's >resonable to continue after one of those (except for Mac and DOS people :^). Best solution (IMHO) is to get sent a SEGV-like signal, but let it work more like SIGSTOP. Then, the user can choose whether to screw over their machine, or not . . . In _most_ processes, it's not that big of a deal (max loss, probably a file or so), but setuid processes would be dangerous to do this on, so only let the superuser continue those. Another parallel process that should be taking place is that the swapper should mark that page bad, and take appropriate action based on that. For one, don't let anyone use that page, now. Also, many faults of this type can be survived, for instance if it occurs in a code segment (just re-read from the executable), or in a file mapped to memory, which would be similar (well, if read-only). Boy, this sounds like fun! I don't envy whoever's putting this stuff together :-) -- scott hess scott@gac.edu Independent NeXT Developer (Stuart) GAC Undergrad (Horrid. Simply Horrid. I mean the work!)