Help with .NET UNO Bridges for LibreOffice

[Stephan Bergmann]

On 8/10/24 15:19, Ritobroto Mukherjee wrote:
> 1) Managed Bridge
> 
> The managed bridge is a completely C# reimplementation of the bridge,
> including the URP protocol, and is based on the ridljar/ and binaryurp/
> modules. It is less fleshed out right now, only containing
> implementations of some of the interfaces and services. I'm trying to
> understand the Java UNO bridge in ridljar/ and the C++ binaryurp/
> modules so I could port them to C#, and they include a pair of classes
> named JobQueue and ThreadPool in there that I'm having trouble
> understanding what role they play and how they handle threads and jobs.
> 
> I would really appreciate it if someone can explain how they work.

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 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.

> 2) Native Bridge
> 
> The native bridge uses P/Invoke to reuse the existing C++ bootstrap and
> bridge code via C#. It is at a stage where parameter-less functions and
> interface attribute getters are mostly implemented. However, I am
> facing challenges with marshaling and unmarshaling various types of
> parameters between C# and native memory, including complex types such
> as arrays and structs, and managing object lifetimes (acquire and
> release calls).

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/?

> Should arrays be pinned or copied to native memory, and same for
> structs? Would lumping all parameter data in a single block of memory
> be better?

Sorry, I'm way to unfamiliar with the UNO .Net bindings to give you a 
useful answer here.