>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.
Nice ideas ; actually the separation is done from the pipe, which buffers update requests. Explicitly buffering is much more elegant. Thanks. regards Lucio _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
