gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Nit


From: Colin Walters
Subject: Re: [Gnu-arch-users] Nit
Date: Sat, 18 Oct 2003 23:50:22 -0400

On Sat, 2003-10-18 at 23:41, Tom Lord wrote:

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

Uh huh.

> Hmmm.  In a "sitting at the bar, casual-philosophic discussion" I
> might actually say that it's a bit of a mystery [...]

It's not at all a mystery to me, and I don't think that would change
even after a few beers.

> 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.

Yes, so...you have just answered your own question.  Why again do you
need me here wasting my time writing this email?

> 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.  

Sure.  But not if the cost is greatly decreased power for script
writers.

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

No, it is not "useful" to consider them unrelated.  Why would you think
so?  They are clearly related.

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

In the longer term it is quite possible.  Saying "it's broken now" is
not a good argument for saying "let's break it further".

>     > 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.

I didn't say that it wasn't *possible*.  Just that it is clearly more
difficult and less reliable.  You have to come up with a way to
serialize strings, integers, floating point numbers, structures, lists,
hash tables, tuples...and then deserialize them in the other process. 
Then you need a way to send over commands...with arguments...it just
gets very ugly very fast.  Being able to work directly with functions
and datatypes makes life *much* easier for a wrapper.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]