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 03:47:39 GMT
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.

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


Mime
View raw message