Path: utzoo!attcan!uunet!midway!ncar!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!lavaca.uh.edu!menudo.uh.edu!sugar!peter From: peter@sugar.hackercorp.com (Peter da Silva) Newsgroups: comp.sys.amiga.tech Subject: Re: Files larger than available memory. Message-ID: <6694@sugar.hackercorp.com> Date: 3 Oct 90 11:32:13 GMT References: <924@ucsvc.ucs.unimelb.edu.au> Organization: Sugar Land Unix - Houston Lines: 37 In article , mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > In article <483@public.BTR.COM> eeh@public.BTR.COM (Eduardo E. Horvath eeh@btr.com) writes: > 1) Allow the user to (optionally) specify the number of buffers > to use when launching mg. > Sorry, the number of buffers is unlimited, and will stay that way. > Besides which, a single buffer can grow arbitrarily large. [...] Since > the point of paging to disk is to allow editing of files larger than > memory, adding other strange constraints seems counterintuitive. The Amiga is a multitasking and (to some extent) multiuser system. It is desirable that it be possible to limit any program... particularly memory hogs... to less than "all available memory". The consequences of running out of memory in that background compile you're doing are much worse than those of running out of memory in an editor... it just gets slower (and on a hard disk, very little slower... it's still I/O bound on the user). Gotta get those priorities straight. > 2) Provide a "flush out all buffers to disk" command in mg to > free up memory just before launching a memory hog > application. > Not possible, mostly for portability reasons. This one went right over my head. What's so non-portable about a flush command? All the code has to be in there to manage paging blocks out anyway, so #ifdef AMIGA case FLUSHCMD: for(each block) page_out(block); #endif -- Peter da Silva. `-_-' .