>
> I still think that in such a case it should be possible to
> 'test the commitment' by touching all the allocated memory
> while trapping page faults. and fault all your memory from
> 'potential' to 'allocated'. As someone said. it is not sure which program
> when you run out of swap, but I think you might be able to somehow
> change this behaviour to "the program making the request" fails
> (or gets a fault).
>
> You could allocate your memory.
> trap faults.
> touch all of the allocated memory.
> if it faults, you can remap some file to that location to allow the
> instruction to continue.. continue and abort the check..
> exit as needed, OR continue with secure knowledge that
> all your memory is there.
> Alternatively you could allocate your own on-disk swapspace for
> a program by telling malloc to use a file for all your memory needs.
I think the right way to implement this would be define a POSIX P1003.1
"mlockall(MCL_CURRENT|MCL_FUTURE)"
along with a physical memory limit resource. I think this could
be defined to give the requested malloc performance. This is
defined to be not inherited so you'd still need to modify your
program. I absolutely agree this is a can of worms, but this would
be a way to proceed.
Peter
--
Peter Dufault ([EMAIL PROTECTED]) Realtime development, Machine control,
HD Associates, Inc. Fail-Safe systems, Agency approval
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
