[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [platform-swt-dev] Request to get new SWT-API
|
Sadly, Shell.openBlocking() would be another method that could not be fully supported by RAP. Let me explain.
Only to support the SWT main loop, or more precisely
Display.sleep(), we
had to create a complicated system, that starts a separate UI thread for every user session and switches between servlet container threads and UI threads. The problem with this approach is not only the complexity, but the lack of support for session failover - you can't migrate a *stack* from one VM to another. We also
provide a lightweight, JEE compatible mode, that enables failover, but this mode cannot support blocking at all. However, we recommend this new mode because it allows for clustering and consumes less server resources.
It's possible to write SWT apps without blocking
operations, with the exception of SWT Dialogs. For Shells, you can react on close using a Close listener - as you do with other events as well. JFace Window/Dialogs can also be used in non-blocking mode using setBlockOnOpen(false). Only SWT
Dialogs (i.e. ColorDialog, FontDialog, etc.) are opened blocking,
and they cannot be set to non-blocking.
I understand that blocking calls are a bit
more convenient, but they are an exception to the programming model of
SWT where, once the initial UI
is created, all UI code is in event listeners that are called
asynchronously. And (even though this point doesn't count for SWT's threading model) in the light of a computing world that involves more and more concurrency, shouldn’t asynchronous operations be considered more favorable than blocking ones anyway?