Help with .NET UNO Bridges for LibreOffice

[Ritobroto Mukherjee]

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