Subject: Re: leaking iconv handles, wv return type
From: Vlad Harchev (hvv@hippo.ru)
Date: Wed Nov 15 2000 - 07:31:06 CST
On Wed, 15 Nov 2000, Thomas Fletcher wrote:
> On Wed, 15 Nov 2000, Vlad Harchev wrote:
>
> > On Tue, 14 Nov 2000, Thomas Briggs wrote:
> >
> > > > XAP_EncodingManager is assumed to be created no more than 3 times. So I
> > > > didn't care about leaking iconv descriptors - they don't take a lot of
> > > memory
> > > > (no more than 100bytes each). I don't recommend spending time on bothering
> > > to
> > > > close those descriptors.
> > >
> > > I would normally refrain but such obvious flame bait, but I have to ask:
> > > you can't be serious, can you?
> >
> > By serious, you mean "don't joke"? If I don't append smiley, then I don't
> > joke. If you mean "be more responsible" - I am since I know that not
> > releasing iconv handles won't make any harm except of additional 500 bytes of
> > memory not returned to memory heap.
>
> Or under an embedded system where the number of system
> fd's is potentially limited, running out of file descriptors.
> In a long running program (which AbiWord could potentially
> be) then there is no reason that you shouldn't be cleaning
> up after yourself. Compared to the time that we spend doing
> other operations, the work of free() and close() are noise
> and we should do everything we can to prevent the leak of
> _any_ resource (be it memory or file descriptors). Addressing
> this issue now will mean that someone won't have to deal with
> it later when/if it becomes a problem.
As I said, initialize is called only 3 times per AW session. So it doesn't
matter how long you run AW - the amount of leaked memory will be the same.
And AW is not supposed to run in embedded environment.
> Vlad, you are obviously a very capable developer ... why
> are you against taking the 10 minutes that it would probably
> take to properly address this issue?
I don't want to bother with this burocratical issue and force future guys who
will extend XAP_EncodingManager bother studying and then updating
that additional code for sake of 500 leaked bytes that leak completely under
our control. I.e. don't turn freeing them into a policy.
> Thomas
> -------------------------------------------------------------
> Thomas (toe-mah) Fletcher QNX Software Systems
> thomasf@qnx.com Neutrino Development Group
> (613)-591-0931 http://www.qnx.com/~thomasf
>
Best regards,
-Vlad
This archive was generated by hypermail 2b25 : Wed Nov 15 2000 - 07:51:25 CST