mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) (10/09/90)
In article <6708@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes: For allocating fixed size blocks like this, I'd call AllocMem and FreeMem myself. Using fixed-size blocks is a major lose. You either wind up breaking large files into small chunks, or having small files chew up large chunks of memory. Neither is acceptable in a buffer gap editor, and it's even less acceptable if you use a linked list of lines. > So you have to implement your own memory allocation > strategy, that supports giving freed memory back to the system. Why? It's already there. Yes - and you get to choose one of two. The portable one that may or may not actually give blocks back to the OS, or the non-portable one. Some choice. > This > is going to add confusion to the editor, and is a worse than useless > for systems that have real VM. #ifdef Amiga freeblock(b) { FreeMem(b, BLOCKSIZE); } #else freeblock(b) { free(b); } #endif Simply shocking! Yeah, I'd expect you to produce useable code samples. I also figured you wouldn't recommend writing a memory allocation system after pointing out that one is already in place. As previously mentioned, you really can't use a fixed size blocks. You're also making the code uglier, and adding more code to the set of things that must be explicitly dealt with for a port. Obviously, _anything_ the machine can do can be made to work, if you're willing to make the cord sufficiently painfull to port. I've looked at and rejected making mg hand back unused buffers always. The only way I've found to do it is to create a special type of memory (which you apparently want to call a "block"), and add a memory allocation manager that can (if possible) give back the memory to the system. That's _exactly_ what you're doing above, though you forgot the part of the code. The code is simple, but it is more code that needs to be debugged. It's also in the non-portable section of the code, which means that _everyone_ who wants to port the editor has to at least decide whether to use the "portable" version, and possibly debug their own versions. That's a non-trivial hit on portability for a trivial functionality. You want the editor to give all it's memory back to the system? Hit the close gadget; it works like a charm. If you're running the editor resident, then your code even stays in memory. <mike -- Estant assis, de nuit secrette estude, Mike Meyer Seul, repose sur la selle d'airain, mwm@relay.pa.dec.com Flambe exigue, sortant de solitude, decwrl!mwm Fait proferer qui n'est a croire vain.
peter@sugar.hackercorp.com (Peter da Silva) (10/09/90)
OK, you implement it however you want. I'll fix it when you release the source. Limiting the memory usage is even useful for pre-VM UNIX systems (like the ones we have 400 users on at Ferranti). -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) (10/10/90)
In article <6754@sugar.hackercorp.com> peter@sugar.hackercorp.com (Peter da Silva) writes:
OK, you implement it however you want. I'll fix it when you release the
source. Limiting the memory usage is even useful for pre-VM UNIX systems
(like the ones we have 400 users on at Ferranti).
That's the best option. Doing a second memory manager may be more work
than is worth it to you; that was my decision. In any case, be sure to
send the fixed back so I can consider incorporating them. I may not,
but I definitely won't if I don't see them.
I will conceede that I haven't decided how to paging files to disk
will be triggered yet. I may well wind up with something that allows
memory use to be set at start-up time. However, that's _not_ a
priority. As I said, the reason for adding that kind of paging is to
allow editing of files larger than memory. Extra overhead to constrain
the editor isn't on the list.
<mike
--
And then I saw her... Mike Meyer
She was a bright red '64 GTO mwm@relay.pa.dec.com
With fins and gills like some giant piranha fish, decwrl!mwm
Some obscene phallic symbol on wheels.