🚀 go-pugleaf

In article <446df2$3ae@wolfe.wimsey.com> wnight@vanbc.wimsey.com (William Robert Night) writes:
>Kazimir Kylheku (c2a192@ugrad.cs.ubc.ca) wrote:
>: You can block the process until the request can be satisfied. You can
>: raise some sort of exception and let the process handle it in whatever
>: way it wants (including the option to try to restart the request).

>And this is going to work really well on a single-tasking system... What 
>if the process itself is what has (through normal usage) fragmented the 
>memory? Block it until the cows come home?

You still assume that system doesn't have virtual memory.
It was a problem in '84, but all modern CPUs have MMU built in.
If you have paged MMU, fragmentation problem doesn't occur at all: 
all pages have equal size, and continuous area of virtual memory
doesn't have to map on continuous set of pages. If MMU uses variable sized
segments, situation gets slightly worse, but it still isn't a problem:
OS can move physical segments as it wish, change physical addresses in
descriptors and that's all: memory will be defragged and applications 
wouldn't even notice it.

>: In any case, you have saved space by not bloating your code with silly
>: wrappers around an overzealous global heap management scheme.

> You still haven't explained what you'd have the OS do if all the memory 
> was available to meet the request, but was fragmented... Just sit there 
> and wait, or should you let the process move its own data around system 
> memory? Nah, let the OS do it in a reliable and documented way.

Well, if you have MMU, OS can defragment memory in reliable and
transparent to application way. Your app won't even notice defragmentation.
If you don't... multitasking without MMU is a disaster anyway.

Cheers,
	Fat Brother.

Fatal Error: Couldn't enter Windows, use Doors.