|
|
|
|
|
|
Re: Concurrent readers impossible? [message #1843689 is a reply to message #1843634] |
Fri, 13 August 2021 22:21 |
Stephan Herrmann Messages: 1853 Registered: July 2009 |
Senior Member |
|
|
Ed W., in my first post here, I wrote:
"Call me naive, but I had assumed that several readers should not interfere with each other."
I was just asking for clarification, on a matter, where my software engineer's intuition is at conflict with Xtext's method "readOnly()". So, I was naive. I learned the lesson by now.
It was Christian who suggested to file a github issue, the issue just being another channel for discussion, not presuming that Xtext is "wrong".
I could easily join in on the lament about the state of concurrency in Java, but I'm also ready to make do with what we have.
The real difficulty, as I see it, is that Eclipse and Xtext already contain so much control flow complexity and concurrency complexity that the poor little user code only needs to require one lock and we already have deadlock, as neither side knows which locks the other side my require or hold, nor can we rely on any rules what other work might be executing concurrently in which situation, nor do we know who calls me and when. If you are interested in why I believe that 75% of my deadlock is caused by Xtext, have a look at the github issue.
I guess all I'm saying: it really helps A LOT to get some background information about non-obvious aspects of the Xtext design. Even after 10 years of getting my hands dirty with it.
Stephan
PS: I still don't believe it's a good idea that ChangeSerializer spins the event loop ... (did you know it does??).
PPS: My current strategy to avoid the deadlock is: make my complex operation REALLY MODAL, switching as much as possible to single-thread mode, by locking both UI thread and the entire workspace :)
|
|
|
|
Powered by
FUDForum. Page generated in 0.03669 seconds