Thanks for the answers! I'm answering through the lines. > > I usually create a mutex, and use it to manage a small bit of data that > communicates a readiness state.
Of course, I did that before with semaphores and different processes. I forgot. > > BTW, don't forget to either 'join' or 'detach' the threads to avoid > leaking memory, esp. if your app starts and stops threads repeatedly. Good point! > >> Also, the threads.cxx example from fltk-1.1 locks/unlocks in the >> "producer" thread, but that's because it adds rows to the browsers. I'm >> not accessing any fltk widgets, so I don't have to lock, is that >> correct? > > I think that's correct; you'd only need to use FLTK's locks if you need > to do anything to the widgets. As a matter of fact, I think even in my simple example I need some locks even though I'm not accessing widgets from the non-gui thread. That's because a rectangle X gets passed to the drawRectangle() callback as a pointer so by the time it gets drawn in the gui thread it could be overwritten in the producer thread. I guess I don't fully understand the behavior of Fl::awake(). If I pass a callback to awake(), is that guaranteed to execute before awake() returns control to the calling thread? Do I need to lock() the call to awake? Again, thanks for the input. By the way, your video tutorials are excellent. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
