Re: [Gnu-arch-users] Nit

[Tom Lord]

    > From: Joshua Haberman <address@hidden>

    > > I've previously mentioned may reasons why it is better to layer on tla
    > > rather than libarch -- is it really necessary to repeat them?

    > I would like to know them.  Here is what I could dig up from brief
    > "thread archeology":

    > 1) linking libarch  directly into a client program will increase the
    > client process's data space consumption

And, let's add, memory fragmentation.

    > 2) bugs in libarch could cause the client program to crash

    > 3) long-running commands in libarch would have to be made
    >    interrupt-safe

And, (4), the cost of making changes to libarch would spike sharply.

That's a good enough list for now.


    > I really don't think 1 is a concern.  The memory arch needs to complete
    > its operations will have to be allocated at some point, whether its in
    > the same process or a different one.  Does arch even use an amount of
    > memory that is significant compared to what average computers are
    > equipped with?

It can easily use a small percentage of that and, meanwhile, there's
plenty of other processes to compete as well.   Fragmentation is an
issue (tla mallocs and frees strings and arrays like mad).   Leaks are
an issue (small leaks in tla simply don't matter, currently -- making
libarch binding-friendly would change that).  _exit() is a pretty
effective and efficient garbage collector.


    > 2 likewise seems like a non-issue to me, for two reasons:

    > - in my experience of using lots of third-party libraries, we rarely see
    > our application crash in them.  Whether libraries are easier to keep
    > bugs out of, easier to test and find bugs in, or there's some other
    > factor I can't say but that's my experience.
    > - tla/libarch in particular doesn't seem particularly prone to
    > crashing.  I have never had it crash on me once.

But you probably have seen tla bail by printing an error message or
panic message from deep in the stack and then exiting.   For a
short-lived, software-tools-style program, that's entirely reasonable
error handling.

For a binding-friendly library it's completely unacceptable.  Every
error condition would have to turned into an error return, and
propogated up through all callers (or else we'd need an
exception-handling mechanism with non-local exits and some form of
unwind protection).  That means that many callers will have to be
modified to "return early" in circumstances where they currently
don't.  That in turn means that the "clean-up code" in every function
would have to be made harrier -- plenty 'o new code to add to make
libarch binding-friendly.

So I'm glad that tla doesn't crash for you today, but in the process
of making libarch binding-friendly, it'll be necessary to add many new
opportunities for crashes, and a decent number of new lines of code.

    > You know better than I do what is involved in modifying libarch for 3. 
    > Is it a lot of work to make libarch support this?

It's the same issue as error-propogation -- the need to
upwardly-propogate errors and clean-up program state in response to
them.


    > Compare these advantages to the disadvantages that have been mentioned:

    > 1) a serialization format has to be devised and maintained
    > 2) deserializers have to be written for every target language

Which is utterly trivial for the specific data we're talking about --
(1) is essentially done except for tweaks.   (2) is trivial in most
high level languages.

    > 3) os-specific process management code has to be written for every
    > target language

Most high-level languages already have that.

    > 4) a way of propagating errors meaningfully has to be devised

No, the process exit status and stderr output already does that.
That's a simple and uniform mechanism.  It's less expressive than some
binding-friendly-libarch alternatives we can imagine, but we haven't
seen any compelling examples of why greater expressiveness is needed.


    > Basically it involves re-implementing all the features of an API over a
    > serial communications line just to keep libarch in a separate process.
    > It's hard for me to see why you find this compelling.

Because it's a lot easier than you make it sound.

Don't forget that, originally, arch was implemented as a bunch of
shell scripts.    The functions that are today in libarch were
originally "an API over a serial communications line" (more or less).

But look, ultimately it's a cost/value trade-off.   You think the cost
is low enough?  You do it.   Go ahead -- do a good job of transforming
libarch to be binding friendly.    Probably only take a week or
two....

-t