> In my first app I used Fl::lock, but when the app is growing I have to
> be careful not to create deadlocks, as threads can communicate with
> each other.

Sure; but the Fl::lock() is a mutex, so you must only take it immediately 
before you want to modify the widgets, and you release it as soon as possible.

You never hold the lock for any longer than is necessary, and you do nothing 
but fltk GUI operations within the lock, so there should be no scope for 

That said, if you need to be handling incoming data asynchronously (and at a 
high rate) you want to be separating that out from the GUI update process 
anyway - see Edzard's note on queuing up data for processing, then dealing with 
that at "user rates", not at input rates.

Selex ES Ltd
Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 
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

Reply via email to