Re: .NET or Mono functions in PG

James Mansion wrote:
> 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.

Depends on what you mean by a problem. It's something you need to think
about, and think hard about, and be sure you deal with. But it can be done.

And yes, the housekeeping threads could be a problem. If you end up with
for example something called on the GC thread calling back out into
"native mode", while the backend is doing something completely different.

And yes, it would be the same as embedding Java. And it has been done
with pl/java, so it can be done :)

An interesting thing could be to look at if code could be "stolen from"
or even better shared with pl/java, if this is the road to go down.

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

Agreed, that'd be a good start. But it would certainly be convenient if
you could have access compatible with the System.Data stuff, since
there's bound to be a lot of code (and coders) that know about that...

//Magnus