axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damitha Kumarage <damith...@gmail.com>
Subject Re: [Axis2] Duplicating array list
Date Fri, 24 Nov 2006 04:17:24 GMT
Damitha Kumarage wrote:

> Samisa Abeysinghe wrote:
>
>> As far as my understanding goes, a simpler solution would be to 
>> introduce an extract_flow method to message (and operation). This 
>> would return a pointer to the array list representing the flow and 
>> set the respective message's flow to NULL. As you seem to know from 
>> which operation you are going to extract and to which operation you 
>> are going to set it, this would work fine with minimal copying.
>
>
> Great. I will try this and let you know. However the solution I gave 
> solved all seg fault problems in sandesh2.
>
But when I think about it there seem to be a problem. According to your 
solution it is assumed that the extracted from operation does not have 
further use of the flow. But it is not so.
Damitha

>>
>> Samisa...
>>
>> Damitha Kumarage wrote:
>>
>>> Hi,
>>> Damitha Kumarage wrote:
>>>
>>>> Samisa Abeysinghe wrote:
>>>>
>>>>> I would alway prefer a reference rather than a copy - specially 
>>>>> something like an array list. It is too costly yo copy.
>>>>> Rather it is far better to keep track of stuff and release based 
>>>>> on life time. Inside the engine, for most of the cases, just a 
>>>>> reference serves the purpose.
>>>>
>>>>
>>>>
>>>>
>>>> I agree. But think about this. In the scenario I pointed out I'm 
>>>> creating a completely new operation called create_seq_op.
>>>> app_msg_op_desc has flows and when it is freed those flows are 
>>>> freed. I am not clear how to share these flows between the two 
>>>> operations and avoid double free with the existing system. Could 
>>>> you please help me with this case?
>>>
>>>
>>>
>>> OK I'll give more details. Currently how flows are added to 
>>> operation is like this,
>>> in svc client
>>>
>>> info = AXIS2_CONF_GET_PHASES_INFO(svc_client_impl->conf, env);
>>> AXIS2_PHASES_INFO_SET_OP_PHASES(info, env, op_out_in);
>>>
>>> Then what happen in phases info is that it will create a new 
>>> in_phases array list and fill that with newly created
>>> phases. Currently these phases are freed when msg related to that op 
>>> is freed. What I can do is, instead of keeping
>>> those phases in msg I can keep them in phases info itself and do 
>>> like this,
>>>
>>>            phase = axis2_hash_get(phases_info_impl->op_in_phases, 
>>> phase_name,
>>>                AXIS2_HASH_KEY_STRING);
>>>            if(!phase)
>>>            {
>>>                phase = axis2_phase_create(env, phase_name);
>>>                axis2_hash_set(phases_info_impl->op_in_phases, 
>>> phase_name,
>>>                    AXIS2_HASH_KEY_STRING, phase);
>>>            }
>>>            AXIS2_ARRAY_LIST_ADD(op_in_phases, env, phase);
>>>
>>> where op_in_phases is the array_list set as flow in the msg. So now 
>>> when msg is freed, only op_in_phases array list is
>>> freed and phases are freed by the phases_info. Also if we don't want 
>>> a generic array copying function I can have
>>> a flow copy function in phases_info.c. It just do a shallow copy of 
>>> the passed flow. Since the operation specific
>>> flow naturally should belong to the operation(msg) it is natural to 
>>> give a shallow copy of the flow to the new operation.
>>>
>>> So my problematic scenario is solved  like this
>>>
>>> outflow = AXIS2_OP_GET_OUT_FLOW(app_msg_op_desc, env);
>>> new_outflow = axis2_phases_info_flow_copy(env, outflow); /* do a 
>>> shalloy copy */
>>> AXIS2_OP_SET_OUT_FLOW(create_seq_op, env, new_outflow);
>>>
>>> So now each operation free(shallow) it's own flow, but the phases 
>>> are freed by the phases_info.
>>>
>>>
>>> Please see the attached diffs for more details of the changes
>>>
>>> Damitha
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>


---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org


Mime
View raw message