axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samisa Abeysinghe <samisa.abeysin...@gmail.com>
Subject Re: [Axis2] Duplicating array list
Date Thu, 23 Nov 2006 13:43:34 GMT
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.

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


Mime
View raw message