From dev-return-1571-apmail-apr-dev-archive=apr.apache.org@apr.apache.org Thu Mar 01 18:58:59 2001 Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 48784 invoked by uid 500); 1 Mar 2001 18:58:54 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 48764 invoked from network); 1 Mar 2001 18:58:51 -0000 Date: Fri, 2 Mar 2001 05:44:39 +1100 From: Luke Kenneth Casson Leighton X-Sender: lkcl@samba.org To: Jeremy Allison Cc: Multiple recipients of list , tng-technical@samba-tng.org, samba-team@samba.org, dev@apr.apache.org Subject: Re: FW: RPC restructuring finished (mostly). In-Reply-To: <3A9E769B.E9FE7462@valinux.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N [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 ----- "i want a world of dreams, run by near-sighted visionaries" "good. that's them sorted out. now, on _this_ world..."