I asked the newbies, but got no response. Maybe an export will have some ideas.
I am trying to resolve an issue with using X in a multi thread environment. LynxOs 3.0.1 with pthreads & XFree86 4.1.0 running on Pentium III-850. Programmed in C++. For those unfamiliar, LynxOs is just a real-time Unix. I found early on that making X call from more than one thread was a problem. Well, not a big problem really, I now have one thread which runs the X loop. All X calls are either as a result of X events or are stimulated by another thread. The former (Xevents) are handled by the X event mechanism and hence run from the main loop, in the X thread. No problem. The later (other threads) I have dealt with based on a suggestion in the Motif Programmers Manual for the handling of signals, that is to use XtAppAddTimeOut with 0 delay to provide an "interrupt" into the X event handling. This should then make the handling the same as the first. This is all well and good except for two problems... The X main loop blocks based on new events and the current earliest timeout in the list. Adding a new timeout does not wake-up the main loop. Hence you have to wait for the next event or timeout before the new timeout is recognised. I have got round this to some extent by constantly running a timer (self re-triggering) at an interval representing my maximum acceptable latency (50ms). This serves to wake the X main loop and cause the new timer events to be recognised. Can anyone suggest a better mechanism than this (e.g. something which will really wake the X loop but safe from another thread)? Any solution must not allow the X loop to dominate, I have significant processing to perform in the other threads. A second problem has recently come to light. It is this problem which prompted me to seek advice on both problems. I have just incorporated a new feature into the application, it can now synchronise the local date & time to an external reference clock. It came as a surprise to me that the X loop runs on absolute time (I had assumed that it would use a relative time such as system time since turn on). However, the net result is that if the time is advanced, timer events occur early (no problem), but if retarded, some timers can be in for a long wait. Now it may be that my only solution is to enhance my timer triggering class with its own list of active timers and a retriggering method coupled to the time change class and then wait for the next event to poke the main loop into action. But, maybe someone out there has a simpler solution. Any suggestions would be appreciated, Alan 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 Thales Underwater Systems on +44 1963 370 551. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
