Shared memory and IPC

[Luke Kenneth Casson Leighton]

On Mon, Sep 10, 2001 at 08:44:24PM +0200, Branko Èibej wrote:
> You're passing around structured defined in IDL, right? 

yep.

> Therefore you 
> know exactly where the pointers are. 

... urrr...   yes.

> I assume pointers are the only bits 
> that will cause problems if the segment isn't mapped to the same 
> addresses in both apps.
> 
> If all of the above is correct, and MMAP_FIXED fails (as it sometimes 
> will) or isn't available (as it often isn't), you can simply fixup the 
> pointers by adding an offset -- the difference between the addresses of 
> the mapped area in the two apps. That would still be faster than a 
> memcpy (except if you're passing arrays of poitners).

[arrays of pointers are surprisingly common, or rather, complex
data structures in enumeration arrays of users/groups/SIDs/printers
etc. with several pointers to strings, SIDs etc. in the Windows
NT Domains IDL structures i've seen - are surprisingly common.

that's not to say that someone doing their own DCOM app would
have a lot of arrays of pointers]


okay, i get it - combined with dave cb's and jim d's posts.

what you're _not_ recommending is to be marshalling and unmarshalling
the data into a flat stream, but instead:

to walk the data structures using the IDL definition, changing
all pointers *in-place*.

okay.

whilst in theory this is an extremely good idea, in practice i
think it will be about eight to ten man-weeks' full-time work
to action, which discourages me but might not discourage other
people.

the freedce idl compiler stands at 50,000 LOC.  it's a back-end
generator which generates further code that can be compiled
to perform idl marshalling/unmarshalling, on a per-function
basis.

so, like i said, in theory, it's easy to plug in a new
back-end on a run-time switch that will generate pointer-fixup
code.  in practice, the verbose nature of DCE/RPC IDL makes
this quite a large project.

luke