[Top][All Lists]

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

[Nmh-workers] Cleaning up format memory management

From: Ken Hornstein
Subject: [Nmh-workers] Cleaning up format memory management
Date: Sun, 11 Nov 2012 22:33:49 -0500

Since we've been talking about the format language, there is something
I've wanted to clean up for a while: the format compiler/interpreter's
memory management.

The format routines don't have a very clean API, and there is a lot of
exposure of the internals of the format implementation to other programs.
And some of the memory management is a bit weird.  Exhibit A: see
uip/replsbr.c:replout(), specifically "compbuffers" and "nxtbuf".  Okay,
what happening there is that in the name of efficiency every time a
component we are interested in is "seen" by us, we switch out the current
buffer we're using with a new one and save the old buffer (which contains
the contents of that component) in the hash table.

I'm sure back in the days of a VAX 11/750 that made sense, but now?  I'm
thinking we'd never notice the string copy.

In addition to that, calling the format compiler more than once per program
is problematic.  Exhibit B: uip/mhlsbr.c:compileargs().  The problem here
is twofold: the format instructions contain pointers to the hash table
entries and thus memory is leaked every time fmt_compile is called (okay,
it's never freed NOW, but still) and if you want multiple format strings
to refer to the same message, you have to go through all of these
contortions to make it work.

To explain that, here's how things work now:

- You call fmt_compile(): hash table of "interesting" components is reset
  and built anew.  Any component you care about it your format string is
  stored in a hash table.  Each format instruction referencing a component
  points to the component entry in the hash table.
- You call m_getfld() and you peek in the hash table every time you get
  a new component.  If that component is in there you store the
  component text in the hash table entry.
- When you call fmt_scan(), the component text for each component is retrieved
  from the hash table as needed.

The problem is if you call fmt_compile() multiple times and then
want to interpret each set of instructions on the same message, you'll
only have the correct component hash table from your last call to
fmt_compile().  My code to support reply filters was the first time
anything has wanted to do that, hence the nasty mess I have in there

So, I'm proposing that I clean up the API and simplify the memory management
(although it looks like I'm going to have to refcount the component hash
table entries to make it work right).  Objections?  Okay, fine ... a better
language would be nice.  So little time ...


reply via email to

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