Re: [Gaim-devel] Resolving IP addresses in Gaim

[Ethan B. <ebl...@cs...>]

[below]

Greg Hudson spake unto us the following wisdom:
> On Aug 21, 2006, at 7:39 AM, Ethan Blanton wrote:
> >Actually, this is the textbook case where people who don't understand
> >threads *think* it's a textbook case for threads.  In fact, the _only_
> >time that threads make sense is when you have a huge amount of shared
> >data that both sides of the divide need to be able to access rapidly.
> >In cases such as this one, where the information to be passed back and
> >forth is very small, cooperating processes are a huge win -- because
> >memory faults in one process are isolated from the other.  With the
> >thread scenario, a memory corruption bug in the lookup thread can
> >stomp data in the main process; in the cooperating process scenario,
> >it cannot.  In fact, with a careful interface, a complete failure in
> >the lookup process affects only *one* thing in the main procees; a
> >single lookup fails.
>=20
> This argument isn't terribly compelling; it amounts to "good design =20
> uses address space separation when it can, and whenever you need a =20
> separate thread of control, that's an opportunity."  But Gaim and =20
> most other large multi-function programs abandoned that design =20
> principle long ago; if it aimed for maximal address space separation, =20
> plugins would be processes, rather than dynamically loaded libraries, =20
> the UI would be in a separate address space from the main control =20
> logic, etc..

I disagree, it is *very* compelling.  The argument of "we didn't write
a completely moduler message-passing program, so don't use message
passing at all" just doesn't float.  Interestingly, the *original*
core/ui split design was precisely this -- a core process
communicating with a UI process via Unix sockets.  Additionally, both
the Tcl and D-Bus APIs allow for extra-process plugins, and I
encourage their use.

> If Gaim had a non-blocking way of using hostname resolution (e.g. if =20
> functionality like ares or dyndns were built into operating systems), =20
> no one would think twice about building the lookup functionality into =20
> the same address space as the rest of the code.  All we're doing is =20
> making one system library invocation; that doesn't rise to the level =20
> of needing address space separation.  It just isn't a "huge win".

I agree -- if we had an asynchronous lookup code, I would put it
directly into the main process.  However, I think you're
underestimating the undesirability of threads.

> A more compelling reason to avoid threads on Unix is that it's more =20
> demanding on the debugger.  When I'm using gdb on a program which =20
> makes use of threads, my life is intrinsically a lot more complicated =20
> ("you want a backtrace of which thread?") and, more importantly, I =20
> run into a host of gdb or OS bugs which frequently render the =20
> debugger useless and send me back to printf debugging.  This isn't =20
> prejudice from years ago; I ran into this situation on a RHEL 4 =20
> machine just yesterday working on openssh, and my work on it wasn't =20
> even vaguely related to the code areas it was forking threads for.  =20
> The situation on other Unix-type operating systems like Solaris is =20
> even worse, in my experience.

This is just icing on the cake made from reasons threads suck, really.

Ethan

--=20
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764