Eclipse Community Forums - RDF feed
https://www.eclipse.org/forums/
Eclipse Community ForumsParallel Serialization
https://www.eclipse.org/forums/index.php/mv/msg/1105698/1833941/#msg_1833941
We found the recent blog post: https://blogs.itemis.com/en/how-the-code-generation-process-in-xtext-can-be-executed-parallely. This post was regarding code generation execution in parallel. This included mentioning that EMF is not thread-safe and to take special care regarding proxy resolution.
The recommendation at the end of 203 was to run a static initialization in a single thread before running the actual serialization. While the recommendation at the end of 906 was to create a custom GrammarProvider and install the adapters upfront.
In our scenario, we generated the ASTs serially and the resulting grammar does not have proxy elements. Each AST has its own Resource, but they all share the same injected ResourceSet. However, even after running an initial serialization serially, we occasionally still receive a serialization exception. Is there guidance on how much serialization needs to be performed by the static initialization?
I have prototyped a custom GrammarProvider, similar to the 906 solution, but haven't tried it enough to see if it resolves this issue.
Overall, is there guidance on how to safely perform serialization in parallel?
]]>L R2020-10-28T14:40:20-00:00Re: Parallel Serialization
https://www.eclipse.org/forums/index.php/mv/msg/1105698/1833942/#msg_1833942
=> i fear there is no guidance]]>Christian Dietrich2020-10-28T14:42:51-00:00Re: Parallel Serialization
https://www.eclipse.org/forums/index.php/mv/msg/1105698/1833943/#msg_1833943
I doubt that parallelization of the serialization is doable with reasonable effort. Sorry, we can't offer guide on that approach, we did not do it that way before.]]>Karsten Thoms2020-10-28T14:55:32-00:00Re: Parallel Serialization
https://www.eclipse.org/forums/index.php/mv/msg/1105698/1833957/#msg_1833957
Parallel GrammarProvder.. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=460978
In Xtext 2.8, an evolution to Xcore.ecore was mishandled so that it became a breaking change to the *.xtextbin, preventing OCL and QVTd maintaining compatibility. I therefore replaced the XXX.xtextbin reader with its mandatory new feature, by an auto-generated XXXGrammarResource that builds a grammar singleton via new-feature-tolerant Java code; faster and more compatible. Since the underlying GrammarResource is a boring singleton, I suspect that one or perhaps two "synchronized" keywords could make the GrammarProvider threadsafe.
A new declarative formatter for Xtext also provides a serializer that is driven by static auto-generated metadata. It too probably only needs a couple of outer "synchronized" keywords to be threadsafe. Further, the internal algorithm is a tree descent for which the descents to children could be parallelized. Parallelizing the final M2T StringBuilder would also be possible if the ultimate StringBuilder deferred concatenating trees till almost done. This is still work in somewhat slow progress.