Hello everyone, (This part is in response to Mr. Bergmann's reply)
> The overall idea is that UNO is multithreaded across the involved processes, > and each such abstract thread has a unique ID that it carries across all the > processes (and different language runtimes, in each process) it executes on. > The runtimes then need to make sure that each abstract thread is mapped to > exactly one process thread (and that no two concurrently active abstract > threads share a single process thread, as that could lead to deadlock). The > details are at > <https://wiki.documentfoundation.org/Documentation/UNO_Execution_Model>. So to clarify, every thread has an UNO generated ID, independent of its OS thread ID. Is this thread ID unique across a bridge or only unique in a process/environment? What I can get from the code is that UNO Threads are modeled as a pair of JobQueues, one sync and one async, managed by the ThreadPool. Is this correct? > So the typical implementation is that in a process you have a thread pool > with one thread for each abstract UNO thread that is currently active in that > process. A call coming in via URP is modeled as some job that is sent to the > matching process thread; and when those threads execute synchronous calls > that reach out to remote URP endpoints, they block waiting on a corresponding > "done" response, which is turned into a job that unblocks the matching > process thread again. And I assume the asynchronous calls are similar but without a "done" blocking job? Alright, thank you very much for the documentation link and the explanation! > I'm not very familiar with the existing UNO .Net binding, but I wonder why > you would need to implement something new from scratch at > bridges/source/net_uno/ rather than continue using what is already available > in cli_ure/? That's because the older implementation in cli_ure/ uses a Microsoft specific extension to C++ called C++/CLI, which allows seamless interop between C++ and C#. This is however not cross-platform and hence needs to be replaced with a combination of standard C++ and C# to achieve cross-platform bridging for the GSoC project. Apart from this cli_ure/, being very old, used some deprecated C# APIs as well. (This part is in response to Mr. Thorsten's reply) > That's probably too much of an implementation detail, to elicit useful > feedback here. Unless someone has a different, strong opinion: > * look into the options, pick the most performant/future-proof one (i.e. one > that likely won't need changing, when .net API gets updated) > * failing a clear winner: do it similarly as the old cli bindings Yes, I've realized the wording is a lot like a "how do I code this" kind of question. As I mentioned the cli bindings used C++/CLI, so a lot of the interop details are handled by the compiler and are not immediately obvious. I've decided to go with a combination of pinning and copying where suitable, in a similar fashion to how call parameters are marshalled by UNO. Best regards, Ritobroto
