I've got an FTLK 1.1.7 app running on Linux and Core2 Duo processor.
The app uses a framework which has its own network communications thread, and
our app supplies a callback function that the framework calls when new network
messages arrive.
Our app's callback function looks something like this:
void onNewMessage(...) {
...
Fl::lock();
(modify state of some widgets)
Fl::unlock();
}
The problem we're having is that sometimes it takes a really long time to
acquire that lock - even up to 3 seconds occasionally.
I assumed that the there must just be heavy contention for the lock, but from
what I can tell, that's not the case. I've modified FL_lock.cxx to report
various details about how long the lock is held, how long it's released, which
threads are involved during lock contention, etc.
As best I can tell, the main thread (executing Fl::run()) always holds the
Fl::lock for very brief periods of time. Nothing that would seem to explain
why it takes my framework's callback thread taking up to three seconds to
acquire the lock on occasion.
Does anyone know why I might be experiencing this? Is it some known FLTK or
pthreads+linux issue?
Also, I've read here:
file:///usr/share/doc/fltk1.1-doc/HTML/advanced.html#multithreading
about an alternative scheme using Fl::awake(...) and Fl::thread_message(...).
Are my problems possibly caused by using Fl::lock/unlock rather than
Fl::awake/thread_message?
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
