Re: [Gnu-arch-users] Nit

[Joshua Haberman]

On Sat, 2003-10-18 at 21:55, Tom Lord wrote:
>     > You could do all of the above just as easily with a language
>     > binding to libarch, and then use your favorite programming
>     > language on top.
> 
> You can equally well, better even (which is my point) layer your
> favorite programming langauge on top of the tla program rather than
> the libarch api.
> 
> 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
2) bugs in libarch could cause the client program to crash
3) long-running commands in libarch would have to be made interrupt-safe

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?

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.

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?

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
3) os-specific process management code has to be written for every
target language
4) a way of propagating errors meaningfully has to be devised

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.

Josh