On Tue, Aug 28, 2007 at 03:18:53PM -0500, Dustin J. Mitchell wrote:
> Even barring [the existance of pthreads], glib uses a generic system
> for its thread library, so we (or someone else) could write a new glib
>; interface for the new HPUX threading library if necessary.
>
> Yes, that wrapper is a lot more than threads; it's documented here:
> http://library.gnome.org/devel/glib/2.8/ (we're assuming a minimum of
> version 2.2, which is *really* old)

I hate to see amanda requiring such a large library to build. glib
isn't exactly lean & mean, and seems to have a significant amount of
code churn. I'd prefer for amanda to have as few dependencies as
possible while still offering a given feature set.

> > 2) the event loop model is harder up front, but once built, is much
>; > easier to debug and maintain.
>
> This is quite true, but sacrifices os-level concurrency. That is, you
> can't simultaneously be copying a large buffer in with a read() call
>; and out with a write() call, while also compressing data in another
> buffer (well, unless you use fork(), but then things get tricky).

by fork() being "tricky" I assume you mean "can't get away with the kind of
sloppy memory sharing hacks you can with threads". (:

for the above scenario, I don't see threads being a performance win over
fork(), and I posit bugs and design flaws will be easier to debug with a
fork() implementation vs threads.

put another way, what benefit does programming to threads give over
fork()?

--
Aaron J. Grier | "Not your ordinary poofy goof."; | agrier%40poofygoof.com">agrierpoofygoof.com
The United States is the one true country. The US is just. The US
is fair. The US respects its citizens. The US loves you. We have
always been at war against terrorism.