On 11 Apr 2008, at 23:51, Lisa Rapchick wrote: > 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. :)
OK - my notes later in the previous post were meant to address that - i.e. by using add_timeout or add_fd to poll for or catch (respectively) messages from the other threads. Those techniques allow callback functions in the main thread to be triggered without breaking out of the Fl::run() loop. > 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). For dismissing dialogs? I don't think you need a thread for that at all. When you show the message dialog (from the main thread), also call Fl::add_timeout(...) with the time set for your warning message. Then, when the timer expires its callback can check if the dialog is still displayed, and if it is, dismiss it. I imagine that most (all?) your timing needs can probably be met by using add_timeout, without running a separate thread at all. Similarly, if your comms channel is coming in on anything that looks like a unix file descriptor (and that covers a lot of options) then Fl::add_fd can allow you to handle that without a separate thread - depends on the volume and complexity of the traffic, I think. For really complex or high volume traffic a thread specifically to handle that makes sense, while for a low volume input, handling it via add_fd in the main thread is very effective (and simpler to get right!) > >> FWIW, does your code run built native on a desktop linux box? That >> > 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. That's a pity - I generally advocate wrapping up the interfaces in as generic a fashion as possible. The extra work it takes to create the wrappers usually pays you back in debug time. Much easier to debug on your desktop than in the target... That's part of why I'm using fltk at all - portability. > >> Are you using a kernel with the RT hacks in, BTW? That >> > 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. OK, it was just something extra that might be throwing a curve into things... > Thanks again -- this continues to be a really helpful conversation. Your most welcome - hope we can sort it out! -- Ian _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
