Success! Happy to report that it has been a week, and no more crashes in malloc. We're down to only a couple show/hide/label calls from threads, and they are safely inside lock/unlock pairs. So that is a huge success.
To respond to a couple of your ideas (both good ones): We're not using add_timeout (to close our timed dialogs) yet, but yes, that seems to be a no-brainer that we should switch over to using that. As soon as I get my fires put out. Unfortunately our communications does not look like a fd. But we could wrap it so it does. That probably won't happen this month, but its a good idea for our cleanup which should be the following two months. I have another weird problem now (but I'll start a new thread for that. > 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
