[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnu-arch-users] Re: [MERGE REQUEST] Re: Another step for libtla
From: |
Tom Lord |
Subject: |
[Gnu-arch-users] Re: [MERGE REQUEST] Re: Another step for libtla |
Date: |
Sun, 11 Jul 2004 14:31:04 -0700 (PDT) |
> From: Matthew Dempsky <address@hidden>
> Tom Lord <address@hidden> writes:
> > > I've also started work on step c of Tom's original plan (switching
> > > libawk to use alloc_limits), and have a 5kloc changeset for
updating
> > > relational.c and all of its callers. However, I need pointers on
how
> > > to handle associative.c.
> > What's the issue? (or is it just the stuff that follows)
> The associative.c stuff uses hackerlab's hashtree functions which seem
> to expect the hashtree_rules parameter to specify the alloc_limits to
> use, but associative.c only has a single static alloc_limits
> parameter.
> I suppose one way would be to modify that hashtree_rules before each
> hashtree function call, but then the hashtree_rules needs a mutex for
> making it multithread safe, and that doesn't seem very clean/pretty.
Yikes. Nah.
The hashtree interface doesn't require the hashtree_rules parameter to
have a stable address across multiple calls: it only requires the
fields of the rules to be consistent across multiple rules.
So, why not have the associative.c functions declare a hashtree_rules
structure as a local variable for each call, fill it in with the
supplied alloc_limits and the fixed comparison function, and do it
that way? That should sidestep the threading issues you are thinking
of.
> > > Also, if I need to change where I put alloc_limits in the argument
> > > list for any of the relational.c functions, I can easily do that
(I
> > > just put it at the beginning of all of them since it was the
> > > simplest).
> > Just to make explicit what I think you're saying: it sounds like you
> > realize it should go between the return parameters (if any) and the
> > arguments, right?
> Right (just like with Pika's FFI), however, a few of the functions I'm
> not sure if you consider them in or out parameters. Specifically, I'm
> concerned about the following functions:
> void rel_add_records (alloc_limits limit, rel_table * table, ...);
> void rel_add_field (alloc_limits limit, rel_record * r, t_uchar * field);
> void rel_append_x (alloc_limits limit, rel_table * out, rel_table t);
> void rel_uniq_by_field (alloc_limits limit, rel_table * table, int field);
Those are fine as is. The expanded rule is something like:
~ output-only parameters to the left of alloc-limits
~ input-only and input-output parameters to the right of
alloc-limits
~ to the extent it isn't crazy, input-output parameters
to the left of input-only parameters
In pseudo-grammar:
<param-list> := <output-params> <alloc-limits>
<input-output-params> <input-params>
> Like I said, I aded the alloc_limits to the beginning simply because
> it seemed like the safest default, but I have the patience to change
> it anyway you'd prefer.
Those four look just fine.
> > > Finally, the reason I skipped ahead to c rather than do step b
> > > (eliminate exits, panics, and safe_* calls from -utils), is I
wanted
> > > to know how error handling should be done in those. Will a simple
> > > return value (-1 or null as appropriate), or do we need to
propogate
> > > an error number too?
> > From libawk?
> The error code elimination step (step b) is actually about removing
> the non-local exits from libarch-utils, but there are a few functions
> that do I/O in libawk that panic if there's any problem, so I suppose
> this is applicable there too.
Yes, it is. Library code which does not implement a `safe_' function
should, with rare exceptions, not call a `safe_' function. They can
call a `safe_' function but only in cases where no recovery from an
error is possible.
> > A short-cut that may make it easier to do error propogation upwards
> > incrementally is to also add "safe_" wrappers for errno-returning
> > libawk functions and change callers to use that. Then callers can be
> > picked off and converted to the error returning forms one by one.
> Right, I can do that easily.
Yup. That's the spirit of the exercise. Small,
correctness-preserving, functionality-enhancing transformations.
-t