> > Well, this is what I was hoping to achieve by shipping all gui actions > > over to the fltk thread to execute. > > OK, but not forgetting the key point that, for reliability, the GUI > thread has to be the main thread, and the non-GUI stuff goes in the > child threads. > Some time ago, I had a program that ran "fine" for a long time, then > started to throw really odd errors on win32 hosts, from time to time. > Turned out I was creating then destroying a widget in a child thread > (doh!) and although it all seemed to be working fine, Things Were Not > Right. > A little switching round fixed it up just fine.
Yeah, this is where a static guarantee by the type system that you are only running gui events in one thread is nice... but your use of "main" thread here worries me. I had interpreted it as "must be the same thread", but is the actual restriction here "must be the thread started by main"? Which platforms have this restriction anyway? > What platform are you on, BTW? And are you aiming for portability to > other platforms? OS X. I'd like to run on linux. win32 is not a priority, but why burn bridges unless I have to? Is win32 the only one with the main thread restriction? > > Anyway, it's up and running and seems to basically work, using my > > windows-as-event-collectors hack. It requires a dynamic_cast to get > > an Fl_Window to an EventCollectorWindow, but I can't really see a > > better way. I'm losing a few events when the windows shut down, but > > that's probably a bug in my code. > > Are lost events on exit an issue? I mean, if it's closing anyway... They're events I don't care about, but the fact that I'm losing them and don't know why is worrisome. > > I had also thought of running the gui as a completely separate process > > communicating via IPC, as a way to insulate the main application > > against c++ crashes, but the need to come up with an RPC protocol to > > ship the data over seems like a hassle. Has anyone done that with > > fltk? I know there are things like D-Bus and other RPC thingies out > > there that are meant to help with this kind of thing, but I don't > > really have any experience with them. > > It doesn't have to be anything fancy, so you don't need to get into D- > Bus and so forth - just hanging on the ends of a named pipe will do > it, and you just send the events you are interested in, much as your > EventCollector is doing, I imagine. Yeah, but I also have to send the gui modification requests, query gui data structures, etc. and that means serializing and deserializing, no matter the underlying transport protocol. > But if your existing implementation is working, it's not obvious that > would be any better. (C++ crashes aside, of course - mind you, my > code doesn't crash.... ;-) Writing uncrashable c++ is my main plan. Automatically saving frequently is plan B in case the unthinkable happens. ... which is also why I turned exceptions on, so that the assert failures and range-checked accesses can be caught. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
