> > 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...
Well I was still seeing some weird behavior, even with (I think) all the locks in my worker threads. So I decided to aim towards moving ALL my show/hide/label calls to be from the main thread (or callbacks from main). I'm not there yet -- I still have a couple of things in threads, which are also inside locks. > > >> > >> 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... At them moment I am not using Fl::run at all. And Fl::wait() is only in one place: a while(true) loop in the main thread (after all the widgets are created). Then after Fl::wait() returns, I am testing Fl::thread_message to see if I got a message from an Fl::awake() call from one of the worker threads. If so, do some show/hide/label stuff. Then back to the top of the loop. I don't see how I can could test for messages (from Fl::awake()) from a worker thread if I use Fl::Run() -- maybe I'm being dense. Its been a long two days. :) > > >> > > 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... > We're not using any of that stuff. > 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. > But I am interested in the Fl::add_fd for the communications channel that is coming to me from outside the box. This is one of the two reasons we have other threads. The other is just a 'timer' thread (actually it just uses sleep at the moment) for things like idle timeout and deciding whether we have displayed warning/error messages long enough (we're timing them rather than making them modal). > 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. No, at least not in the short run. The communications drivers are hardware-specific and we don't have them wrapped well enough to fake them out with another type of input. > 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? As far as I know we do not have any RT mods. There are some custom drivers but that's it. This isn't hard realtime. At the moment we're using the default linux scheduling. Thanks again -- this continues to be a really helpful conversation. > -- > Ian > > > > > > > > > > > _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
