> microwindows-0.91, and nxlib 0.45. I'm not sure if that
> answers your "Graphics layer? Window manager...?" question.
> My background is embedded systems, not graphics, so the
> terminology is new for me.
Microwindows and nxlib were pretty much the answer. What target
hardware, BTW?
NOTE: At this point I usually go off on a rant about the troubles I had
(years ago now) getting microwindows and nxlib to work right, and I
usually suggest folk just try running XF86 or Xorg on their embedded
target (I did, years ago), since most targets are perfectly capable of
running a "full" X-server these days, and all sorts of weird
compatibility issues just magically disappear... But if it is working
for you, that's fine.
> First, I had to rebuild fltk with the appropriate
> enable-threads switch to get Fl:lock/unlock to show up in my
> library. I'm surprised it worked as well as it did, without
> being thread-aware library.
Yup, threading is like that - it appears to be working fine for years,
then chaos...
As we roll out more multi-processor platforms, that's going to get a lot
worse. Are we all looking forward to the fun?
> I'm now in the process of adding
> the lock/unlock pairs everywhere. So far, its not breaking
> anything. :)
It might even be fixing things!
> 1. You referred me to the 1.1.8 docs. I read chapter 10 but
> not the whole thing. How much different is that threading
> behavior from 1.1.7 which I am running? Should I upgrade?
> Are there any compatibility issues I should be aware of?
The threading behaviour is not significantly different. Matthias added
some extensions to the ::awake mechanism, and some other tweaks, but the
functionality is equivalent and the API is pretty much the same.
But I don't think Chapter 10 was added until after the 1.1.7 docs were
released, so you can't read that chapter in the 1.1.7 docs...
I'd advocate updating, but not for threading support per se, just to get
all the bug-fixed 1.1.8 goodness. Most of the time, you shouldn't see
any difference at all, I hope!
> 2. From the 1.1.8 doc:
>
> > Don't call Fl::wait(), Fl::flush() or any related methods that will
> > handle system messages
>
> Can you give me an idea what the "any related methods" are?
Hmm, tricky. I'm not entirely sure... Anybody?
Certainly I'd avoid Fl::check(), or any of the ::add_timeout,
::add:idle, ::repeat_timeout, ::add_fd functions...
> 3. Before I started all this editing, I had a main that
> called Fl::run()
> and then another thread that called Fl:wait(1.0); in a loop
> (with other stuff). After reading your docs I changed main thread to:
>
> Fl:lock();
> while (true) // Its embedded so there's no exit
> {
> Fl:wait();
> }
Well, I always call Fl::lock before I even create my widgets (although I
think that's just superstition) and I always call Fl::run() in the main
thread.
> and I got rid of the Fl:wait call in the other thread.
Yup. Can't call Fl::wait in a worker thread. Well, not safely, anyway.
> But then I wasn't getting the screen to change the first time
> I expected it to. So as an experiment I changed main to
>
> Fl:lock();
> while (true) // Its embedded so there's no exit
> {
> Fl:wait(1.0);
> Fl:flush();
> }
>
> and it did the trick. Do you have any comments about that?
Use Fl::run()?
> So far I'm still planning on keeping the show(), hide(),
> image() and label() calls in the other threads, protected by
> the locks. But if necessary, I can do the
> awake/message/callback thing so that it is all from main.
I think, as long as the widgets are instantiated in the main thread,
showing/hiding them from a helper thread, suitably protected by locks,
is safe.
Let us know how you get on, of course...
Cheers,
--
Ian
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
