> I've got an FTLK 1.1.7 app running on Linux and Core2 Duo processor.
I would advocate stepping up to 1.1.9 as a matter of course, because it
has a number of useful fixes.
But... None that I think are directly relevant to this problem (although
there is some rework of the threading support, so you might find it
responds differently... Hopefully better!)
> 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.
That sounds very odd. I have no immediate idea about what that might be,
I would not expect the lock to be held for any length of time, and your
tests (below) seem to suggest it is not.
Tricky. I guess we'd need to see more of your code, or a worked example
that manifests the behaviour, or something.
> 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?
Not that I know of.
For what it's worth, I did something vaguely similar sounding a while
back, but rather than locking from the network thread, we simply had the
network thread send notifications to the main thread via a pipe.
The main thread used Fl::add_fd() to monitor the pipe, then did all the
GUI updates "locally" in the main thread, based on what came over the
pipe.
This was done as there had been an idea to separate the threads into
separate processes at one point.
This worked very well - certainly, we did not see the delays you are
experiencing.
> 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?
Those are not really intended to be used instead of locking - rather, I
think they are intended to be used as well as locking.
For example, in a worker thread, I would advocate always calling
Fl::awake(); just before calling unlock, to make sure that the main fltk
thread was notified to deal with your changes as soon as possible, that
sort of thing.
SELEX Sensors and Airborne Systems Limited
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14
3EL
A company registered in England & Wales. Company no. 02426132
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
