On 11 Apr 2008, at 16:56, Lisa Rapchick wrote: >> >>> Cirrus 9307.
OK >> I'm convinced we were doing it wrong before (no locks) but the >> locks/unlocks certainly haven't solved my problems -- I still have >> the same lack-of-redraw issues, same seg faults in malloc. > > I'm currently working on getting everything into calls from the > main thread, using the awake/thread_message mechanism. If you have threads, you must use the locks in the worker threads, so... >> >> Use Fl::run()? > > As far as I can tell, using the awake/thread_message mechanism > requires me to use Fl::wait() instead of Fl::run() that you are > steering me towards :) Why so? I don't follow - can you explain? You should use Fl::run() in the main thread. You can not use either of them in the worker thread... >> > One last question: should I be worried about STR675? I don't > think I'm directly calling anything in fl_ask.H, but that doesn't > mean something internal isn't. Only if you use any of the built-in pop-up dialogs (e.g. fl_alert, fl_ask and friends). They *must* be used from the main thread, since they transiently create and destroy GUI window objects, which, as I pointed out before, is a No-No. The same is true of any widget that creates/destroys GUI objects - that *must* be done in the main thread. But you can show/hide widgets from the helper thread. So, if you wanted to pop a file-chooser, if you created it hidden in the main thread, you can (probably!) show it from elsewhere. But you can't create and show it from a helper thread at all - not without weird things starting to happen... So fl_ask and friends can't be popped from the helper thread - if you are trying to do that, you need to get your helper thread to ask the main thread nicely if it would pop the dialog for it... In which case, having the main thread call ::add_timeout to install a poll is possibly the easiest (but less neat) way to go. On a non-win32 system, you can get simple IPC by using Fl::add_fd to listen on a pipe for that sort of inter-thread comms, for example. Then the fltk main loop will see the pipe comms and respond. FWIW, does your code run built native on a desktop linux box? That might be an easier way to debug threading issues than struggling with it on the target, and the underlying kernel is broadly the same in this area. Are you using a kernel with the RT hacks in, BTW? That might impact the GUI responsiveness, since the RT scheduling doesn't guarantee fairness in the way that the generic scheduler does, which might be relevant? If so, what are you doing about task priorities and such? -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
