When many calls to glFlush (X_GLsop_Flush) occur in
a short period (~256 glFlush/frame at 30fps), the next
call to X may freeze XDarwin for several hundred
In our application, this occurs every second on average
with a 50% variance.
One client side stack during the freeze is below. The
particular X function that freezes is not relevant. What is
common is that select() will block on the X call following
a series of glFlush calls.
TRCoords.c: XTranslateCoordinates (wt_dpy, s->shell,
root, 0, 0, &x, &y, &child);
XlibInt.c: _XReply (dpy, (xReply *)&rep, 0, xTrue)
XlibInt.c: (void) _XRead(dpy, (char *)rep, (long)SIZEOF
XlibInt.c: result = Select(highest_fd + 1, &r_mask,
NULL, NULL, NULL);
During the freeze, CPU usage drops to zero.
The behaviour occurs on Dual G4 systems and does not
occur when one CPU is disabled. It recurs if the CPU is
Behaviour occurs in all XDarwin version from 1.1 up to
and including 1.12a.2.
Other non-X OpenGL applications running imultaneously
are not affected by the freeze. Multiple instances of the
affected app freeze asynchronously. Note that there are
no (or very few) intervening calls between the 256
glFlush calls. Removing the glFlush calls eliminate the
Our application works on many other platforms under
the X Window System without exhibiting this behvaiour.
The platforms include: SGI Irix, HP/UX, IBM AIX &
Linux, Sun Solaris, and PC Linux, among others.