[DotGNU]SEE and interaction with vm's

[Gerard Toonstra]

Hi people,

Last night Gopal and I tried to get this plugin working in a little 
framework for the SEE daemon to proof the concept of plugins would work.

The plugin contained the vm entirely, linked statically, but starting it
up it already dumped core at the first initialisation method. gdb
revealed this was related to stack problems. 

It was opened using dlopen() and we think this may be at the "core" of
the problem. Eventually myrddian entered the channel and confronted us
why even running a plugin vm is a bad idea and that it should actually
IPC with the SEE instead. (a vm dumping core for other reasons would
also dump the SEE, which brings down all the runtimes together).

For this reason, we're looking for the best mechanism for SEE->vm
interaction. 

One of the methods immediately proposed was shared memory. If someone
reads this and is convinced this is a really bad idea, please share your
thoughts.

Another method I am proposing and start to favour more is CORBA. Reason
is mainly that it allows remote connectivity and the IDL is basically
the contract of interactivity between SEE and vm, plus dev.time
shouldn't take very long at all (no protocol implementations, just
compile the IDL and implement 'what' it should do).

I would like to hear your ideas about the above, but also alternatives
you think should fit. You could use the following requirements
(unofficial) as guidelines:

1. Fast!
2. multi platform and easy to port.
3. Easy to find bugs (readable what it does).
4. Mix text and binary content easily without running into possible
problems. (fgets(), while c != '\0' etc. over sockets for example may
end up problematic because of binary streams in comms.)
5. thread-safe, no race conditions. (or suitable locks available)
6. Reliable. A reply is always given.
7. Broken 'connections' are detected ( if SEE goes down ), so that   
appropriate action can be taken.
8. Timeout setting when SEE hangs (connection there, but no reply).
9. No likely corruption of data.
10. Only for future so far: remote accessibility of SEE.

Thanks for your time,

Gerard