axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Susantha Kumara" <susan...@opensource.lk>
Subject RE: memory management and AXIS_DEFINED_ARRAY
Date Tue, 01 Jun 2004 09:26:36 GMT
Hi Alek,

What I have mentioned below are how the policies at server side. Let me
list both client side and server side memory management policies,

Server Side
-----------
The policies are,
1. Any objects passed to skeletons by Axis (created either by Axis
Engine or wrappers) are not memory managed by Axis. These are
created/populated/passed to skeletons and it's the responsibility of the
skeleton to keep it or delete it.

2. Any objects returned by the skeletons will be deleted (deallocated)
by Axis after they are serialized. So the skeletons should not return
any objects if they need to keep across several method calls (any
persistent data).


Client Side
-----------
The policies are,
1. None of the objects passed to stubs by Client application will be
deleted by Axis Engine or stub. Axis Engine just use them for
serialization. But any memory allocated within Axis to facilitate
serialization (function pointer tables etc) will be memory managed by
Axis. So its the responsibility of the
client application to keep or delete any objects it passed to stubs.

2. Its also the responsibility of the client application to delete any
objects returned by stubs (created either by AxisEngine or stubs)These
objects are not memory managed by Axis. Axis Engine takes care of
managing any memory allocated to facilitate de-serialization of returned
objects.
 

---
Susantha Kumara
Virtusa (pvt) Ltd.
Office : +94112714385
Mobile : +94777420453

> -----Original Message-----
> From: Susantha Kumara [mailto:susantha@opensource.lk]
> Sent: Tuesday, June 01, 2004 3:08 PM
> To: 'Apache AXIS C Developers List'
> Subject: RE: memory management and AXIS_DEFINED_ARRAY
> 
> Hi Alek,
> 
> 
> > -----Original Message-----
> > From: Aleksander Slominski [mailto:aslom@cs.indiana.edu]
> > Sent: Friday, May 28, 2004 10:28 PM
> > To: Apache AXIS C Developers List
> > Subject: memory management and AXIS_DEFINED_ARRAY
> >
> > hi,
> >
> > how is it supposed to be used - if i return new allocated
> > AXIS_DEFINED_ARRAY will it be automatically deallocated?!
> 
> These AXIS_DEFINED_ARRAY s are always passed by value. So Axis doesn't
> need to do any memory management with it. But any memory pointed to by
> its m_Array member will be de-allocated after serialization.
> 
> See ArrayBean::~ArrayBean()
> 
> >
> > for example is this valid way to do echo? i have seen it in
> > InteropTestPortType.cpp so that should be fine though in this case i
> do
> > not understand who is de-allocating memory as xsd__int_Array is
passed
> > as input and returned as output? shouldnt service clone the array or
> > auto pointer be used?
> 
> The policies now are,
> 1. Any objects passed to skeletons by Axis (created either by Axis
> Engine or wrappers) are not memory managed by Axis. These are
> created/populated/passed to skeletons and it's the responsibility of
the
> skeleton to keep it or delete it.
> 
> 2. Any objects returned by the skeletons will be deleted (deallocated)
> by Axis after they are serialized. So the skeletons should not return
> any objects if they need to keep across several method calls (any
> persistent data).
> 
> >
> > xsd__int_Array Benchmark1PortType::echoInts(xsd__int_Array Value0)
> > {
> >     return Value0;
> > }
> 
> Here this is perfectly OK because the skeleton doesn't need to keep
the
> passed array.
> 
> >
> > and what about returning new value?
> >
> > xsd__int_Array Benchmark1PortType::sendInts(int length)
> > {
> >     xsd__int_Array arr;
> >     arr.m_Size = length;
> >     arr.m_Array = (int *) malloc(length * sizeof(int));
> >     // fill in array with values
> >     return arr;
> > }
> 
> This is OK. But memory inside arr will if be deallocated by Axis
Engine
> after serialization.
> 
> >
> > will it be de-allocated?
> 
> Yes
> 
> > do i miss something (documentation, examples)?
> >
> > thanks,
> >
> > alek
> >
> > --
> > The best way to predict the future is to invent it - Alan Kay
> 



Mime
View raw message