Just can't get enough of that Moose!

[Michael David WINIKOFF]

> 	It think the problem is not with virtual memory.  The problem is in
> a system which utilizes virtual memory but allows tasks to allocate memory
> which is guaranteed to always exist in physical memory (using MEM_PHYSICAL).

Yes.

> This means less space is available for virtual memory to play around in.
> Consider if on a PC with 4MB physical memory I did:
> 
> 		MemoryAllocate(3*1024*1024,MEM_PHYSICAL);  // Allocate 3 megs
> 
> 	The rest of the system would be screwed.  I don't want to restrict
> physical memory to just device drivers (like with the other MEM_ flags) but
> there's no good way to limit how much physical memory a task can use.  I can
> see the need for this type of memory (audio and video applications) but those
> require special device drivers anyway.  Can anybody think of a reason a normal
> application might require a portion of its memory to be physical?   Is there
> any application which just plain wouldn't work if it couldn't respond to some
> event fast enough?

Anything "realtime" by definition.
Multimedia.
You'd probly want network stuff to have a fast response time.

I think limiting physical memory to device drivers is quite reasonable.


> 
> I'll volunteer to start to work on that glossary - it sortof goes hand in hand
> with the specs.  Can anyone give me the precise definition of a thread?  My
> OS book doesn't really define it well...thanx!

A process that completely shares the address space of it's parent?
(minus the stack and registers)

> 
> 
> 				Dennis
> 


--------------------------------------------------------------------------------
Michael Winikoff
winikoff@cs.mu.oz.au
Computer science honours. University of Melbourne, Australia.