Hi, I've got an issue which I've been 'google-fu'ing without much luck. We have a legacy program which has been plagued by an issue for a long time and I've been tasked to investigate/fix.
The program uses XMotif2.1 (required due to dependency on an old GUI designer) and runs on a RHEL7 machine (previously RHEL 5 and before that RHEL4). Normal GUI event processing relies on a re-entrant Xt callback using the XtAppAddTimeout call. This works fine, unless the system clock is set backwards, which occurs due during an NTP sync of the system (which can happen at any point during the program). When this occurs, it appears as though the program is frozen. According to my research, the way Xt handles timeouts is by determining the expiration time (system time + expiration interval) and waiting until that absolute time is reached, rather than using a monotonic clock. So, if the timer is waiting for a second to elapse, but during the wait the system time is set backwards by 18 minutes, the timer will wait for 18 minutes and 1 second before going off (i.e. reach the original expected expiration time).
I've found very little information on the web about others experiencing this issue and any suggestions for a solution. We've tried detecting the time jump in a separate thread and then attempting to cancel, via XtRemoveTimeout, and then restart the timer. But, we haven't had much luck. The best solution I've heard so far was to manage the timer outside the X event loop and use XtAppAddWorkProc instead.
This might be a long shot. But, does anyone have any experience with this that could provide some insight. TIA