[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Multithreaded applications and GTK+
- From: Jamie <jdl28 student canterbury ac nz>
- To: gtk-app-devel-list redhat com
- Subject: Re: Multithreaded applications and GTK+
- Date: Sun, 31 Oct 1999 01:48:01 +1300
Juhana Sadeharju wrote:
>
> I think using IPC and separating GTK from such multithreaded application
> is eventually the right way. But I really would like to hear about this from
> more experienced programmers. Are there some patterns for this kind of
> programming? Patterns or common rules, whatever.
>
I have been creating a maths application using threads and Gtk, and
can't see any reason to think that gtk and multithreading don't mix.
Choosing ipc and non-multithreading gtk applications is only changing
your problem form from one set to another.
When designing an application, there are a number of questions to ask
yourself when you think using threads is a good idea:
1) Is there any part of the program that could function as a separate
thread? such as a computationally intensive function that can run
largely independent of the UI and the rest of your program?
2) What can't it be done in another process? Remember that when using
another process, interprocess communication is still a must, and if you
use shared memory (a high probably if you were thinking of using threads
in the first place), then you still have to deal with all the problems
sharing memory has.
3) Is what I want to do going to affect the responsiveness of the UI in
any way? If it is, then threads is probably going to be a great help.
There is nothing worse than having the UI suddenly stop responding
because it is suddenly doing a great lot of computation behind the
scenes. If you have used kmail (the version with rh6.0), you'll know
what I mean.
So, if you decide to go with a multithreaded application, the idea
usually is to separate the GUI from the rest of the program. Don't
bother sticking parts of the gui into threads, that creates unneeded
complications. Looking back to your original email suggests to me that
you require threads anyway (or have some specific reason to use them).
If you wish to update the clist, I would suggest creating some function
such as:
updateCList( gchar *text)
This would be called by all the threads when you wish to update the
clist, and this function itself could worry about locking memory etc.
Hope this helps
--
Jamie Love
jlove@clear.net.nz
jdl28@student.canterbury.ac.nz
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]