Messages in this thread | | | Date | Mon, 18 Jan 2010 17:01:59 +0200 | From | Gleb Natapov <> | Subject | Re: [PATCH v6] add MAP_UNLOCKED mmap flag |
| |
On Mon, Jan 18, 2010 at 03:49:58PM +0100, Peter Zijlstra wrote: > On Mon, 2010-01-18 at 14:32 +0000, Alan Cox wrote: > > > this kind of control. As of use of mlockall(MCL_FUTURE) how can I make > > > sure that all memory allocated behind my application's back (by dynamic > > > linker, libraries, stack) will be locked otherwise? > > > > If you add this flag you can't do that anyway - some library will > > helpfully start up using it and then you are completely stuffed or will > > be back in two or three years adding MLOCKALL_ALWAYS. > > Agreed, mlockall() is a very bad interface and should not be used for a > plethora of reasons, this being one of them. > There are valid uses for mlockall() and even if the interface is bad there is no alternative right now, so why not fix one of it problems?
> The thing is, if you cant trust your library to do sane things, then > don't use it. > Agreed, the are things that sane library should never do: exit() or output debug info to stdio or meddle with memory mlock/munlock behind application's back.
-- Gleb.
| |