Re: [Gnu-arch-users] Nit

[Tom Lord]

    walters (>>>):
    >>> It would be way better to just make libarch be friendly to
    >>> wrapping by other programming languages.

    lord: (>>)
    >> I wonder what I can do to disabuse you of this mistaken notion.

    walters (>):
    > Respond to my arguments against it, instead of saying stuff like:

    >> Hmm.   Why do we have processes at all?   Why not just run everything,
    >> os to apps, in one big process?

    > This is your argument??

No, that's my attempt to ask a question that would give me some
insight into your "world view" in this area.


    > Obviously you know why we don't run everything in one process.  

Hmmm.  In a "sitting at the bar, casual-philosophic discussion" I
might actually say that it's a bit of a mystery --- something vague
about the emergent properties of the macro-scale universe and their
interaction with the economic/social/political process of producing
software (which are themsleves emergent properties of the macro-scale
universe).  As basic as the question "why not one big process?"
sounds, I don't think it has an easy answer -- just a lot of
observations that might be relevant.  So, "nope", I don't _know_ why
we don't run everything in one process -- though I have observed that
it works out nicely in practice and can wax philosophical on why that
might be so.   [adding this at the last minute:   I'm about to hit the
"send" keybinding for this message.   That'll invoke a subprocess
which I'm quite confident won't crash my Emacs process.   Are "emacs"
and "sendmail" in this case "related"?   I dunno -- is that really a
meaningful and important question?]


    > But > let's go through the two major reasons that come to mind:

    > 1) One program can be reading from a disk while another is waiting for
    > input

So what?   Multiple threads and asychronous I/O are old hat -- the
combination of those two solves that problem for the "everthing in one
process" model.   Of course, if we start adding library foo to make
multiple threads act like multiple processes then, pretty soon, we'll
have reimplemented multiple processes - poorly.


    > 2) Unrelated programs can be kept in separate address spaces, so my word
    > processor crashing doesn't affect my database

Aha! (I wish.)

I happen to think it'd be just swell if a crash-causing bug in tla
itself didn't cause a crash in a higher-level process that happens to
use tla.  In the process model, what would the higher level
application get as output?  Roughly, it'd get "something went wrong"
-- and that's a generic condition that it has a chance of handling
pretty gracefully.

So, yes, indeed:  your changeset librarian and your higher level app
are, for this purpose, usefully considered "unrelated" in the sense
you refer to.   



    > Neither of these apply to wrapping libarch, because the whole idea of
    > the wrapper *is* to be tightly integrated with libarch.  For example, in
    > a Python wrapper I'd like to be able to convert errors into Python
    > exceptions.  Exceptions are a *much* nicer way of dealing with error
    > situations.  Doing this with a subprocess would entail trying to keep
    > track of state in the wrapper and restart the library subprocess with
    > that state so that the program could sensibly continue after handling an
    > exception.

I'm not too sure what to say other than that, from a pragmatic
perspective, you're fantasizing.



    > Another reason is that passing structured data around is difficult over
    > a pipe, but works a lot better in the same process.

That's just plain false.

-t