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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
