This is the mail archive of the
mailing list for the Cygwin project.
Re: Adding madvise function in cygwin with a #define
On Jan 11 20:12, jdzstz - gmail dot com wrote:
> I have read cygwin "posix_madvise" code, that is in "mmap.cc" file and
> "madvise" linux code and posix especification:
> * CYGWIN => mmap.cc file:
> * LINUX => madvise man:
> => madvise source:
> * POSIX => posix_madvise specification:
> Your argument "madvise is more powerful than posix_madvise" in linux
> is correct, the diference about standard "posix_madvise" and linux
> "madvise" are the number of advices that admit in "int advice"
> parameters, Linux implementation admits 10 options but standard Posix
> only defines 5.
For a start, please note that the Windows MM does not support any
advises. So the posix_madvise function behaves exactly as specified.
It checks the validity of its parameters and then just ignores the
advice since the OS doesn't support it anyway.
There are two big differences between posix_madvise and madvise.
Madvise doesn't handle the advice as advice, but as a command. In
contrast to posix_madvise, it returns with an error if it can't support
the given advice.
Madvise supports flags which affect the memory mapping behaviour on fork.
Given that madvise returns an error if something can't be supported,
an application which relies on this behaviour will be dis-functional
on Cygwin, or at least would have a potentially serious security
Consequentially, *iff* Cygwin implements madvise, it would have to
be implemented along the lines of:
madvise (void *addr, size_t length, int advice)
I'm wondering if that's really feasible.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple