awt issues with recent version of X11

[Mark Hindess <ma...@googlemail.com>]

During the M9 freeze there was some discussion [0] about HARMONY-6123 [1].

I've had a look at this issue.  I've attached a patch to the above
JIRA that attempts to add calls to XLockDisplay/XUnlockDisplay around
a single call (XNextEvent) that appeared in the backtrace for this
bug.  Sadly, it causes a deadlock with one thread waiting with the
(new) lock in XNextEvent and another (presumably trying to obtain a lock)
in XSendEvent.

(Aside: Why does XNextEvent require explicit lock calls when XSendEvent is
clearly making them implicitly/internally?)

Since XNextEvent is intended to block until an event becomes available *and*
is required to hold a display lock, I can't see how this can easily be
resolved.  Google reveals that some projects solve this by:

1) doing all Xlib calls on a single thread,
2) using XPending and busy wait (loop/sleep) waiting for an event or
3) rewriting to use the new xcb/xcbutil instead of xlib

I'm not particularly enthusiastic about any of these - 2 is least effort but
horrible.

Anyone have any bright ideas or comments?

Regards,
 Mark.

[0] http://markmail.org/message/mcngtqjtdphwno3w
[1] https://issues.apache.org/jira/browse/HARMONY-6123

Re: awt issues with recent version of X11

[Nathan Beyer <nd...@apache.org>]

I just ran the full classlib test on HEAD in Ubuntu 9.04 with GNOME
desktop running and none of these assertions popped up. They only seem
to pop-up when running the tests using Xvfb. I don't know what this
means that the problem isn't an issue or if it's just delayed.

-Nathan

On Mon, May 18, 2009 at 8:17 AM, Mark Hindess
<ma...@googlemail.com> wrote:
>
> During the M9 freeze there was some discussion [0] about HARMONY-6123 [1].
>
> I've had a look at this issue.  I've attached a patch to the above
> JIRA that attempts to add calls to XLockDisplay/XUnlockDisplay around
> a single call (XNextEvent) that appeared in the backtrace for this
> bug.  Sadly, it causes a deadlock with one thread waiting with the
> (new) lock in XNextEvent and another (presumably trying to obtain a lock)
> in XSendEvent.
>
> (Aside: Why does XNextEvent require explicit lock calls when XSendEvent is
> clearly making them implicitly/internally?)
>
> Since XNextEvent is intended to block until an event becomes available *and*
> is required to hold a display lock, I can't see how this can easily be
> resolved.  Google reveals that some projects solve this by:
>
> 1) doing all Xlib calls on a single thread,
> 2) using XPending and busy wait (loop/sleep) waiting for an event or
> 3) rewriting to use the new xcb/xcbutil instead of xlib
>
> I'm not particularly enthusiastic about any of these - 2 is least effort but
> horrible.
>
> Anyone have any bright ideas or comments?
>
> Regards,
>  Mark.
>
> [0] http://markmail.org/message/mcngtqjtdphwno3w
> [1] https://issues.apache.org/jira/browse/HARMONY-6123
>
>