[Gnu-arch-users] Re: [MERGE REQUEST] Re: Another step for libtla

[Tom Lord]

    > 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