mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-10-24 18:55:30 +00:00
basic README, nothing really earth-shaking
This commit is contained in:
parent
efd2078839
commit
bc8359d38a
58
extensions/mono/README
Normal file
58
extensions/mono/README
Normal file
@ -0,0 +1,58 @@
|
||||
A CURSORY AND LIKELY MISLEADING GUIDE TO MONOCONNECT
|
||||
|
||||
General Architecture
|
||||
--------------------
|
||||
|
||||
The goal of this code is to provide a two-way bridge between the
|
||||
CLR/.NET/Mono/C#/etc. world and XPCOM.
|
||||
|
||||
We want:
|
||||
- Natural C#/etc. syntax for consumers.
|
||||
- Acceptable performance (wrapper space and call speed)
|
||||
- "Correctness" (maintenance of object identity, reference management).
|
||||
- Dynamic, lazy generation of stubs and interfaces from interface-info.
|
||||
|
||||
We do not want:
|
||||
- People distributing generated stubs.
|
||||
|
||||
To that end, we register for TypeResolve and AssemblyResolve events on
|
||||
our AppDomain (components.cs, RegisterAppDomainHooks). When user code
|
||||
references an interface or stub-proxy that we have not yet generated
|
||||
(and is not special-cased, like nsISupports), our TypeResolve hook
|
||||
triggers the generation of an appropriate class.
|
||||
|
||||
The generation of proxy classes happens in generate-proxy.cs, where we
|
||||
employ the many wonders of System.Reflection.Emit to create a proxy
|
||||
for the indicated interface. The proxy class for a given interface
|
||||
will have specialized marshalling code emitted for the specific
|
||||
interface parameters and index. There is currently virtually no code
|
||||
shared between proxy methods, which is something that we should remedy
|
||||
in the future: a rough census of Mozilla interfaces (circa 1.6)
|
||||
indicates that generating a static helper method or delegate per
|
||||
unique method signature would give us significant savings.
|
||||
|
||||
typeinfo.cs has a bunch of infrastructure for inspecting interface
|
||||
info from the IIM. I am not particularly proud of any of that
|
||||
infrastructure, but it does get the job done at present. Lots of it
|
||||
is likely not even used today, since it largely predates actual proxy
|
||||
generation. xptinvoke.cs is along the same lines.
|
||||
|
||||
(typeinfo.cpp exists mainly because we need C-linkage entry points for
|
||||
P/Invoke, and secondarily because I wanted to reduce mono<->C thunking
|
||||
as much as was easy.)
|
||||
|
||||
wrapped-clr.cs is where the CLR-implementing-XPCOM-interfaces code
|
||||
should go. Today, it basically...who am I kidding? You can see the
|
||||
source, it clearly does almost nothing. I have fantasies about
|
||||
patching the C++ vtable with JITted delegate pointers.
|
||||
|
||||
There's one piece missing to this puzzle (other than all the other
|
||||
pieces): we need to generate metadata-only interface assemblies for
|
||||
people to compile C# against, because our TypeResolve/AssemblyResolve
|
||||
tricks are not enough to get us wired into the compiler.
|
||||
|
||||
Other things that are missing:
|
||||
- AString support
|
||||
- Exceptions
|
||||
- figuring out a good way to map casting to QI
|
||||
- a component loader
|
Loading…
Reference in New Issue
Block a user