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

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

Colin Barrett spake unto us the following wisdom:
> On Aug 20, 2006, at 7:16 PM, Mark Doliner wrote:
> > Ethan didn't like this (I think because it uses threads?), but his=20
> > reasons didn't really convince me.  How do other people feel?  It's
> > pretty easy to revert my change and go back to having lots of crazy
> > and confusing code, if people want.
>=20
> What exactly is his problem with using a thread? Threads are great; =20
> they only start to get hairy when you're passing data back and forth =20
> from one threadspace to another. But this type of task -- performing a =
=20
> blocking call without blocking the UI -- is the canonical, text book =20
> case for threads, and generally results in simple, easy to understand =20
> code -- assuming the library you're using is sane, of course ;)

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.

Windows programmers often think that this sort of thing absolutely
requires threads, but that is due to severe limitations in the Windows
process model, IPC, and process creation performance.  On platforms
which have a cheap fork() and robust IPC, multiple processes are a
clear win.

In this case, Mark's concern is motivated by total code complexity; I
disagree that the complexity of having two implementations (both of
which are bound to be maintained, as Unix requires one and Windows
requires the other, so it's not like there is a real potential for
long-term rot or divergence) is too painful.  The third, non-forking
non-threaded implementation can simply be removed.  If there is a
platform on which neither fork() nor pthread_create() is supported, a
lot of other things Gaim requires probably are not supported either.

I remain in opposition to this change, on the principle that it is bad
design, but I am not going to get in a long debate over it; if no one
else understands or cares that it's bad design, then let it be bad
design.  In this instance, the complexity of the code in the
subservient thread can be kept under control such that the usual
concerns about threading behavior can be minimized.

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