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

[Greg H. <gh...@MI...>]

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.

This argument isn't terribly compelling; it amounts to "good design  
uses address space separation when it can, and whenever you need a  
separate thread of control, that's an opportunity."  But Gaim and  
most other large multi-function programs abandoned that design  
principle long ago; if it aimed for maximal address space separation,  
plugins would be processes, rather than dynamically loaded libraries,  
the UI would be in a separate address space from the main control  
logic, etc..

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

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