multithreading

[Cliff Wells]

On Fri, 24 May 2002 15:10:42 +0200
Nils Kassube wrote:

> Cliff Wells <logiplexsoftware at earthlink.net> writes:
> 
> > I think this is a bit of an overstatement.  Many problems are best
> > expressed as multithreaded programs. Trying to solve a naturally
> > multithreaded problem as a single-threaded app can be more complex
> > and error-prone than the natural
> 
> man fork
> 
> Often you do not need shared memory space. Dealing with shared memory
> and multiple threads can introduce subtle bugs that will be extremely
> hard to reproduce. Using multiple processes is in many cases the
> better solution (on real operating systems).

True, but often you do need shared memory.  If you don't, then fork is good,
but if you do then you will have to start dealing with fifos, sockets or
whatnot to share data between processes.  This is at least as error-prone as
threading and not as obvious to code.   

Honestly, I fail to comprehend the fear of threading often expressed by some
people on this list.  My first Python app was a multithreaded message server
(in fact, the reason I tried Python was because Cygnus gcc didn't have thread
support at the time).  Not only was it my first Python app, but my first
multithreaded app as well.  While it wasn't perfect, it ran without problems
and I encountered no real problems implementing it.  My second app was a
multithreaded GUI client (in Tkinter) for sending and receiving messages from
that server.  Still no real problems.  I feel my programming skills are
adequate, but not exceptional, so I expect that there are many problems that
can be solved safely with a threaded app by someone willing to take the time to
learn. 

Regards,

-- 
Cliff Wells, Software Engineer
Logiplex Corporation (www.logiplex.net)
(503) 978-6726 x308  (800) 735-0555 x308