Re: Updating GUI from a callback using threads

[zentara <zentara1 sbcglobal net>]

On Tue, 5 Aug 2008 21:37:32 -0400
muppet <scott asofyet org> wrote:

> On Aug 5, 2008, at 9:16 AM, zentara wrote:
>
> > So here are some rules to follow that will let things work right.  
> > These can be violated,
> > but you may cause errors,  These rules, if followed, will give  
> > foolproof thread operation.
>
> The other big alternative, of course, is "don't use threads, fork a  
> child process and communicate status and results via a pipe that you  
> monitor from the main loop."  This is a recurring theme here on the  
> mailing list.

> Whether a child process or a thread is more appropriate depends on  
> your problem.

My rule of thumb is "do you need to share variables between children in realtime"?
If yes, threads should be used, unless memory cleanup is a problem. 

If your thread uses huge amounts of memory at times, and little at others, 
the memory use will rise to the peak, and won't be returned to the system until all threads exit.
A forked child will return memory immediately on exit.

If you go with forked children, you have to setup pipes, sockets, or shared memory 
segments to communicate.  Some programmers feel setting up the IPC communications
is simpler than dealing with the myriad problems with thread use.

Threads are not the optimal solution, because shared memory segments
are faster..... BUT threads and shared variables are MUCH easier to use than shared
memory.... so threads are often an easier way.

But threads are a current buzz-word, and people want to use them. 

Also don't think that running threads under Perl is indicative of general
threads usage. 
Using threads in c is alot easier, and memory cleanup is better.
Perl itself introduces alot of hassles.


zentara

-- 
I'm not really a human, but I play one on earth.
http://zentara.net/Remember_How_Lucky_You_Are.html