Re: [Gnu-arch-users] Nit

[Tom Lord]

    > From: Joshua Haberman <address@hidden>

    > I'm pretty sure I understand.  I still think it's a close analogy.  

    > cduffy is proposing wrapping a shared implementation of tla
    > deserializing (call it "libtladeserialize") with bindings to different
    > languages, putting libtladeserialize in the same process as the
    > application.

    > This is very similar to the proposal of wrapping a shared implementation
    > of manipulating arch archives/trees (call it "libarch") with bindings to
    > different languages, putting libarch in the same process as the
    > application.


Och!   I'm such a fool.   Remember we had a list of 4 reasons not to
worry about making libarch binding safe?   I left out (5) and (5) is a
huge, huge, really important one:

   (5) asynchronous and concurrent operation

   High level applications will want to run tla commands, possibly
   multiple commands concurrently, in the background.   To make
   libarch capable of that would minimally require that it be made
   thread-safe.   But beyond that -- it would have to be made thread
   efficient.   For example, by default, the Rx caching engine is
   global and would have to be shared among all threads.   That means
   that two pattern matches, in two threads, will slow each other
   down.

   By contrast, the subprocess model makes asynchronous and
   concurrent execution of tla commands simple and efficient.
    
So, no, an in-process wrapper is rather extremely different from a
separate wrapper.

Man, I can't believe I forgot (5).

-t