> 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"?
Yes - that's what I meant. And yes, that's a pain. > Which platforms have this restriction anyway? Well, hard to say. I know I have encountered it on win32, although not at first, it was more insidious and "pretended" to be working for quite a while... (The win32 API does include methods that allow you to work around this constraint, IIRC, so fltk could, in principle, be "fixed" here.) I don't know for OSX - I suspect I have seen this problem there, but have no proof. The code has since been modified anyway (see win32...!) so I don't see the problem any more. For the X11 *nixes I think it can depend on which window manager or graphics driver layer you are actually using, so there may not be any straight answer to that one. Others more learned than me might be able to offer something constructive here? > Is win32 the only one with the main thread restriction? Not sure. Don't think so. I always err on the side of caution here... > > 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. Yes. It's probably nothing, but... How do you know you have lost these events, BTW? Is it some sort of race thing, where you *do* get the events, but then send a printf to stderr (say), and the stdio goes away (because your app is exiting) before the io gets out...? > 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. Yes. IPC can be "easy" in the sense that the basic mechanism can be very simple, but is rarely "easy" in the sense that it just works! > 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 generally builds without exception support by default (it wasn't widely and reliably supported in the early days) so that might prove "interesting". SELEX Sensors and Airborne Systems Limited Registered Office: Sigma House, Christopher Martin Road, Basildon, Essex SS14 3EL A company registered in England & Wales. Company no. 02426132 ******************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. ******************************************************************** _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
