FW: RPC restructuring finished (mostly).

[Luke Kenneth Casson Leighton]

[cc'd to apr dev because of reference to apr's pool destroy capabilities,
which provide a means to call clean-up functions on sections of memory /
etc].

On Thu, 1 Mar 2001, Jeremy Allison wrote:

> > > long lived daemon.
> > 
> > ... then why not fix those few? :)
> 
> That's what I'm doing :-) :-).

*grin*
 
> > so.  important question.
> > 
> > you can guarantee that in both the client-side and the server-side code,
> > the user-or-consumer (being client and server respectively) is responsible
> > for freeing memory, and that the marshalling/unmarshalling's use of memory
> > is therefore effectively transparent?
> > 
> > remember the NetApiBufferFree() function that has to be called for the
> > usage of the NET* API?
> 
> The idea will be that the caller (client or server) will
> hand a talloc context to the RPC code, and then copy out
> of the talloced memory any structures that need to be
> long lived then destroy the context (freeing everything
> allocated in the call).

the caller?  you mean, in the case of the client-side usage, the caller is
the user of the rpc function, e.g. samr_enum_users(), and the "user" of
samr_enum_users() must be aware of the use of talloc?

the caller?  you mean, in the case of the server-side usage, the caller is
the _samr_enum_users() function, and the "user" of _samr_enum_users() must
be aware of the use of talloc?

if you are in any way exposing the use of talloc to the "callers" - the
users, i seriously recommend that you reconsider.


anyone wishing to plug-in the OSF/DCE IDL compiler into your modified
version is _not_ going to consider being forced to use talloc in their
client / server application.

i've been slowly working / massaging the codebase towards this end
[plugging in the OSF IDL compiler or equivalent].

this requires that you provide, on a per-RPC-service basis, a per-handle
"freeing" function, a memory-alloc function and a memory-free function.

the OSF/DCE code "tracks" all handles, and when they are freed, it
automatically calls the appropriate per-handle "freeing" function - a bit
like apr_pool_destroy does at the moment.

> That way error returns get much easier, as you can just
> return without needing to remember and free everything
> you allocated on the way down the call chain.

yes it does.  however, there are still memory management issues to be
dealt with that i don't think you have addressed.  yes, you've dealt with
the marshalling/unmarshalling, but what about server-side and client-side
memory usage?

what happens, in your proposal, if you do this:

#define samr_connect _samr_connect
#define samr_enum_users _samr_enum_users
... etc

and then TOTALLY remove all the marshalling / unmarshalling code sections 
altogether?

will it work?

will there be any memory leaks?

_that's_ the whole point of dce/rpc: the marshalling / unmarshalling must
be totally transparent.

luke


> --------------------------------------------------------
> Buying an operating system without source is like buying
> a self-assembly Space Shuttle with no instructions.
> --------------------------------------------------------
> 

 ----- Luke Kenneth Casson Leighton <lkcl at samba-tng.org> -----

"i want a world of dreams, run by near-sighted visionaries"
"good.  that's them sorted out.  now, on _this_ world..."