Magnus Hagander wrote:
> I did look at this at some earlier point as well. One big problem at that
> time was that once you embedded mono, yuo had all sorts of threads running
> in your backend ;-)
>
Is that necessarily a problem? You have to compile with a
thread-capable libc and take some
care that the heap implementation is well tuned, but there's no reason
why the mono housekeeping
threads should cause you any problem is there? It should be much like
the embedded Java.
> Another way to do it is "the PL/J" way (I think). Which is starting up a
> separate process with the VM in it and then do RPC of some kind to it.
> Which has more overhead per call, but lower per backend etc. And a lot less
> "dangerous".
>
>
Given that one would want to embed to have very low latency both on
trigger invocation and
on calls back into the data engine, I don't really see the point personally.
I'm not sure how important it is to make the embeded interface look like
a standard
interface (in that way that the embedded CLR in MSSQL does - mostly) or
whether
it can be a thin wrapper over the C API. I think there's good mileage
in starting
with the thin wrapper, then at least some common business logic code can
be used.
James
