Shared memory and IPC
Luke Kenneth Casson Leighton
lkcl at samba-tng.org
Tue Sep 11 04:25:02 GMT 2001
On Mon, Sep 10, 2001 at 08:44:24PM +0200, Branko Èibej wrote:
> You're passing around structured defined in IDL, right?
> 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*.
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
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
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.
More information about the samba-technical