bug-gnu-utils
[Top][All Lists]
Advanced

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

Re: Gettext: Suggested addition of memory allocation clean-up in'intl' l


From: Bruno Haible
Subject: Re: Gettext: Suggested addition of memory allocation clean-up in'intl' library [Again]
Date: Fri, 25 Nov 2005 19:09:56 +0100
User-agent: KMail/1.5

Svante Seleborg wrote:
> > This is acceptable. The function should be called libintl_free_all().
>
> Good enough. If I implement such a function for *Win*32 only (since Ynix
> developers apparently only views things like clean-up as
> CPU-cycle-stealers), will you anyway consider merging it into the main
> distribution

As I said in private mail already, whether I accept a patch in GNU gettext,
depends 1. on whether you convince me, 2. whether the patch is not platform
dependent, easy to maintain and similar.

About convincing me: It depends on the answer to question I asked:

  Why is this a problem? You can
    1. reduce the amount of allocated memory by using LC_ALL=C,
    2. distinguish a memory leak from a static allocation by letting your
       program run a long time and then look at the memory amounts.

> apparently you as maintainer do maintain that the feature
> is unnecessary, and even harmful, anyway in a Unix environment

That's a misunderstanding. When I ask you to show that the feature is
necessary, it's not because I think it's unnecessary. It's rather to
have you state concretely what is the goal of the feature, so that we
can see whether this feature or another one is better for reaching the
goal.

> for us poor *Win*32-developers who do need such crutches - and
> are willing to pay the price in CPU-cycles?

Who said that atexit(free_all_memory_blocks()) would not be costly on
Woe32? It will be costly
  1) on all systems that implement virtual memory with swapping of
     pages, and Woe32 does so,
  2) on all systems that have an L1 or L2 memory cache - and most
     CPUs nowadays have.

> I do want to
> implement the feature, and lack the time to test in anything but a Windows
> enviroment

If you can send a patch for a platform-independent feature, better avoid
platform-specific #ifdefs. The fact that you could test it one platform
only is worth mentioning when you submit it - so that the maintainer
knows what to test on -, but is not a reason for making the patch
platform-specific.

Bruno





reply via email to

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