Mail Archives: djgpp-workers/2000/02/28/09:35:48
> > To Charles Sandmann, about the problem of locking :
> >
> > shouldn't the DPMI server copy the current lock flag for each page
> >that is move by the UNIXY SBRK function ?
Ideally, it should. Some (like CWSDPMI) do. Others don't. Since the
DPMI spec does not mention this behavior, it's not required. It seems the
"resize" function in DPMI is not used by many products - and therefore
can contain some pretty ugly bugs. We saw lots of problems in QDPMI
because of this. This was another of those obscure reasons the current
non-move sbrk() was made default.
I don't have the list anymore of DPMIserver vs. features/bugs - but I am
sure that some of them do NOT move the lock flag if the resized block is
moved. This is one of those really ugly bugs, since:
1) Usually the arena doesn't have to be moved unless you are running
nested images (or on something like Windows which shares memory),
2) Some DPMI providers automatically lock pages or transparently handle
page faults in hardware interrupts,
3) The memory is probably only faulted out on tight memory machines, which
are becoming more rare.
So, this is a real problem with the unixy sbrk under some DPMI providers in
tight memory.
> > In that case, the only think would be to ensure that no sbrk call is made
> >inside the lock_data and lock_code functions, no ?
Much worse - you need to make sure that no sbrk() is called after any lock
function is called. Ever. This is how Quake did it. Allocate all the memory
up front, give back a tiny bit (64K?) so libc would be happy. This
avoided having to recompute the base when using nearptrs, solved the locked
locations, but was a bit of a pain to design the code that way.
- Raw text -