Re: ORBit status?

[Tom Tromey <tromey cygnus com>]

Phil> N.B. COM decides which approach to use by having the user
Phil> specify which objects 'live' in which thread apartments - two
Phil> objects in the same apartment invoke each other's operations
Phil> directly, two objects in different ones have their invocations
Phil> 'marshalled' across the threads via the message queue.

It seems to me that whether or not an object can support multiple
calls at once is a property of the object's implementation, and not
anything else.

So it seems like the right solution is to have the object itself do
the right thing.  E.g., use the moral equivalent of Java
`synchronized' methods if it needs to.

Phil> May I humbly suggest that if we do define a binary interface
Phil> standard, we use the C++ vtable layout as the basis (I think
Phil> that most of the C++ compilers use the same layout).

I wonder.  I know that if you use MI then vtable layouts differ
widely, even in the same compiler (g++ has -fvtable-thunks).

Anyway, I think relying on the internals of the C++ compiler is
probably a bad idea.

Phil> This will mean we don't have to add any layers to in-process
Phil> compiled C++ objects, which will keep the C++ speed freaks
Phil> happy.

It seems to me that using the moral equivalent of a vtable (but not
one that is hidden inside the C++ compiler) will be just as fast for
all practical purposes.

Tom