guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] On Hurd, don't use not implemented madvise()


From: Mark H Weaver
Subject: Re: [PATCH] On Hurd, don't use not implemented madvise()
Date: Thu, 01 Jun 2017 19:29:03 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.2 (gnu/linux)

Manolis Ragkousis <address@hidden> writes:

> On 05/30/2017 10:41 PM, Mark H Weaver wrote:
>> Is there a test we could perform at run-time to discover whether
>> madvise() is implemented?  If so, that would be greatly preferable.
>> 
> Well madvise() on Hurd is a glibc no-op that fails with errno = ENOSYS.
> Maybe I could allow madvise to run once and if it fails set a global
> static variable called madvise_implemented to 0 (by default 1) and use
> this to stop it from running again. WDYT?

I don't see the need for the global static variable, because it should
be quite cheap to call madvise and get ENOSYS, and this shouldn't happen
very often.  So I think we can just ignore the ENOSYS result on Hurd.

> Also from my understanding not using madvise() ends up in slower
> performance but it doesn't create problems to the program, right?

Some programs for Guile 2.2 may take advantage of the dynamically
expandable stacks, because it allows programs to written in a more
natural way.  Such programs may in some cases temporarily allocate a lot
of stack space.  If this memory can never be reclaimed on Hurd, that may
cause problems for some programs.

> Because in this case, it stills compiles guile, the problem is that it
> continuously spams "madvise failed: Function not implemented". I could
> make it not print it when errno = ENOSYS. WDYT?

Right, on the Hurd we should silently ignore ENOSYS, but report other
errors.  On non-Hurd systems, I think we should continue reporting the
ENOSYS error as well.

What do you think?  Would you like to propose another patch?

      Regards,
        Mark



reply via email to

[Prev in Thread] Current Thread [Next in Thread]