It's not just native code. Almost all of SWT is written with an asumption
of single-threaded access.
To make a a widget field freely accessible from another thread
("thread-safe"), it's necessary to synchronize ALL accesses to that field.
There are 38 references to blockSelection in StyledText code.
For a single boolean flag, you could get away with making it volatile. But
for more complex data types (starting with integers), and for more than one
thread-safe field, you'd need actual locks. Moreover, the locks would
likely have to cover whole method bodies, because proving the correctness
of more granular locking isn't easy. Then, all variables accessed in those
synchronized methods would have to become synchronized in other methods
too. The cost of built-in thread safety escalates quickly. That's why SWT
is single-threaded.
Re: checkWidget. Without it, it would be easy to write incorrect
multi-threaded code that works most of the time. It's blockind the
dangerous path of least resistance.
On Mon, May 27, 2019 at 4:58 PM Mickael Istria <mist...@redhat.com> wrote:
> Hi all,
>
> I'm currently working on the topic of moving work out of UI Thread, using
> JDT as main target (bug 538656).
> In my investigations, I've hit the case of calling
> `StyledText.getBlockSelection()` sending a InvalidThreadAccess because
> first line of the method is `checkWidget()`.
> However, this method is mostly a boolean accessor, the state of block
> selection or not is purely inside the Java logic, no JNI. Invoking this
> method from a thread is definitely a harmless operation
> So I'm wondering: why is SWT putting so much `checkWidget()` even on
> simple accessors? Is this something we could get rid of?
>
> Thanks in advance for your insights.
>
> --
> Mickael Istria
> Eclipse IDE <https://www.eclipse.org/downloads/eclipse-packages/>
> developer, for Red Hat Developers <https://developers.redhat.com/>
> _______________________________________________
> platform-dev mailing list
> platform-dev@eclipse.org
> To change your delivery options, retrieve your password, or unsubscribe
> from this list, visit
> https://www.eclipse.org/mailman/listinfo/platform-dev
--
Best regards,
Nikita Nemkin
_______________________________________________
platform-dev mailing list
platform-dev@eclipse.org
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://www.eclipse.org/mailman/listinfo/platform-dev
