Hi,
Thanks a lot for your advice. Here's how I implemented it.
The main process handles all the updates to the GUI. No FLTK calls are made
outside of this thread. The things I added to the main process are:
queue<char*> messageQueue;
pthread_mutex_t messageMutex = PTHREAD_MUTEX_INITIALIZER;
void add_message(char* message) {
pthread_mutex_lock(&messageMutex);
messageQueue.push(message);
pthread_mutex_unlock(&messageMutex);
}
void process_message(char* message) {
// Manipulate GUI stuff based on message
}
Instead of using Fl::run(), I use this:
while (true) {
Fl::wait();
pthread_mutex_lock(&messageMutex);
while (messageQueue.empty() == false) {
char* message = messageQueue.front();
messageQueue.pop();
process_message(message);
delete [] message;
}
pthread_mutex_unlock(&messageMutex);
}
The thread that does socket communication has a pointer to the add_message
function. When it receives a message from a socket it calls add_message with
the message.
Nicholas
> On 4 Mar 2007, at 4:17, Nicholas Schwarz wrote:
>
> > I'm seeking some advice about how to use threads with FLTK,
> > preferably without using FLTK's built-in lock and unlock features.
>
> If the worker thread actually manipulates any of the GUI elements, it
> can really only do so safely if it uses the locks.
> However, if the worker thread simply changes the values of some
> variables that are read by the main (GUI) thread, and the GUI thread
> manages updating of the displayed items, then that can be made to
> work robustly without locks.
>
> You (probably) still need to provide some means to ensure that the
> data items update atomically and are never read by the GUI thread
> part way through writing by the worker thread, but depending on your
> circumstances that may not matter (it rarely/never happens on a
> single cpu machine, and only occasionally on a multi-processor one,
> and even then it may not actually matter!)
> The easiest thing is to use add_timeout in the GUI thread to poll the
> state from the worker threads data stores and use that to refresh the
> display at some sort of human acceptable rate (doesn't have to be all
> that fast - humans are *very* slow).
>
> Any use?
> --
> Ian
>
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
