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.
