AW: [DotGNU]Portable.NET: Embedding issues ..

[Tobias Oberstein]

> Von: Rhys Weatherley [mailto:address@hidden
> Gesendet: Sonntag, 9. Februar 2003 22:24
> An: Tobias Oberstein; address@hidden
> Betreff: Re: [DotGNU]Portable.NET: Embedding issues ..
>

> It should be possible now to create multiple VM instances within a single
> process (feel free to log a bug if it isn't).  As long as you
> have some way
> to synchronise access to a single "ILExecProcess*" value, any
> thread can make
> a call on it.

Great. Good to hear!

> We don't currently have support for multiple
> threads running
> within a VM instance, but that is a separate issue from multiple threads
> outside the VM instance making calls.

No issue - I don't want/need that. I suppose running multiple threads
within one VM instance at the same time would require fine-grained
locking at the object level (e.g. reference counting comes to mind ..)
which would be a big performance hit.


> Being able to load from memory or a custom loader is on our TODO list.

Just to be sure: are different VM instances also isolated in terms
of loaded class code? That is, once the code for some class has be
loaded into some VM instance, it stays there unmodified even if I
load modified code for the _same_ class but into a different VM
instance?


>
> > 3. Transparent object persistence
> >
> > Most important, is it possible to hack the run-time (the CTS?) such that
> > a user can declare new types to be persistable, e.g in C# like so:
> >
...
> > Instances of persistable classes are sharable between all VM instances.
> > All synchronisation is done under the hood by the OO database.
>
> Is this a standard .NET mechanism, or something that you yourself have
> devised?  I'm not really sure what you require in this case.  Is
> sounds like
> you want some kind of remoting facility.  We don't have .NET
> remoting yet, as
> it isn't part of the ECMA standards, but it will come eventually.  If you
> would like to submit patches for it, it will come quicker.

Sorry, I was a bit vague here. I'm not into remoting (which is interesting
though). My embedding application is an OODBMS and I want to better
understand
ways to achieve tight integration of VM/OODBMS with the goal of

 - transparent, orthogonal object persistence
 - efficiency

and it might turn out, that this can best done not at the class library
level, but at the VM level. But I guess I have to first get a better
understanding at least of some CLI/VES details to ask the right questions.

For example, instead of serializing a (part of a) object graph into a byte
sequence which then gets stored in the OODBMS, one might argue in favor of
storing the object graph exactly as it is layed out in the VES. At least
for "value types" this could be possible, if one can force the VES to
lay out a simple struct e.g. like in C - that is "packed".

I've learned that there are ways to control the memory layout of value and
object types

autolayout
layoutsequential
explicitlayout

Common Language Infrastructure (CLI) Partitions I to V
9.5 Class Layout, pp57

One point I don't understand is: in C, there are _fixed_-size arrays, like
in

typedef struct _x {
 int f1;
 char f2[100];
} X;


That is X is a "value type" with a fixed layout. Is there such thing like
fixed size arrays in CLI/VES. Are they value types or reference types?

Thanks a lot, greets
Tobias