FW: RPC restructuring finished (mostly).
Luke Kenneth Casson Leighton
lkcl at samba-tng.org
Thu Mar 1 18:44:39 GMT 2001
[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 /
On Thu, 1 Mar 2001, Jeremy Allison wrote:
> > > long lived daemon.
> > ... then why not fix those few? :)
> That's what I'm doing :-) :-).
> > 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
what happens, in your proposal, if you do this:
#define samr_connect _samr_connect
#define samr_enum_users _samr_enum_users
and then TOTALLY remove all the marshalling / unmarshalling code sections
will it work?
will there be any memory leaks?
_that's_ the whole point of dce/rpc: the marshalling / unmarshalling must
be totally transparent.
> 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..."
More information about the samba-technical