[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Merging event dispatch and toolkit threads
From:       Dmitry Batrak <dmitry.batrak () jetbrains ! com>
Date:       2021-08-17 11:18:30
Message-ID: CAET5FPvrKimt+ynGHuYCY3xNm=Yg4Tvke7Nz3sJoRhizLNL2WQ () mail ! gmail ! com
[Download RAW message or body]

Hello,

Now that applets are deprecated for removal, what do you think about moving
towards the unification of event dispatch and toolkit threads in AWT? In my
understanding, th=D0=B5 separation between them was meaningful only for the
applet
use case, and now it becomes a pure nuisance. E.g. accessibility support
implementation on macOS requires 'invokeAndWait' calls between two threads
in
both directions, and achieving this without deadlocks is quite tricky in
current
implementation. Also, windowing APIs on macOS and Windows are mostly
synchronous, and using them in a synchronous way (without passing execution
between threads) could potentially simplify focus subsystem implementation.
Benefits for X11/Wayland systems would be less significant, due to the
fundamentally asynchronous native APIs, but, even in those cases, having
both
outgoing requests sending and incoming events processing on the same thread
should make AWT code more reliable, as we'll have one less place for
potential
races.

Overall, having only one thread to deal with native windowing APIs, should
make
supporting and extending AWT simpler, and closer to native application
development. I think, some synchronization constructs would still need to b=
e
present - to guard against the invocation of AWT methods from background
threads. But, at least for 'well-behaving' apps, the reasoning about
execution order
would be much easier.

Of course, for existing toolkit implementations (macOS/Windows/X11) the
transitioning will take some time and effort, but for the Wayland
implementation, to
be developed withing Wakefield project, the idea could be implemented from
start.
AFAIU, with Wayland client API, we'll need to dispatch the incoming queue o=
f
events explicitly anyway, and this dispatching can quite as well be done on
EDT.

So, what do you think about the idea in general, and about starting to
realize it in
Wayland toolkit implementation?

Best regards,
Dmitry Batrak
[prev in list] [next in list] [prev in thread] [next in thread]