Resolving cross references in Worker Threads #1349
-
Hi Team, I'm currently engaged in the development of a code generator for a Langium-based DSL. In the code generation process, we leverage worker threads in Node.js to dynamically instantiate new Langium services. Subsequently, we create the Abstract Syntax Tree (AST) model by transmitting the file URI from the main thread. Despite the overall success of the implementation, I'm encountering a challenge related to resolving cross-references. Specifically, I've observed that the cross-reference of a particular object model is readily accessible when examined in the main thread. However, when attempting to access the same cross-reference in the worker thread, it appears to be undefined. Any insights or guidance on resolving this issue would be greatly appreciated Thanks in advance. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 5 replies
-
Hey @vibsid0986, Are you only parsing the document in the worker, or are you also building it? The reference in question neither has a |
Beta Was this translation helpful? Give feedback.
-
Hi @msujew , Thank you for your prompt response. Initially, I focused on parsing the document. However, even when transitioning to the document-building phase, I encountered an obstacle. The build() function, crucial to the construction process, returns a Promise. Unfortunately, worker threads are unable to seamlessly process Promises. Below is a snippet of the code utilized for reference. Kindly inform me if additional information is required for a more comprehensive understanding of the issue.
Thanks in advance. |
Beta Was this translation helpful? Give feedback.
-
Thanks @msujew for the help. |
Beta Was this translation helpful? Give feedback.
Since workers don't share memory, documents loaded in one worker/thread cannot be accessed by any other thread. If you need access to the whole workspace in the worker, loading it via
initializeWorkspace
is recommended.Note that each document is still going through each step of the document lifecycle via the
DocumentBuilder
. There's no real way to prevent this (nor would that be advisable).