> 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 deadlocking. 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 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 fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
