You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Samisa Abeysinghe <sa...@wso2.com> on 2006/11/23 09:21:45 UTC
Re: [Axis2] Duplicating array list
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.
Samisa...
Damitha Kumarage wrote:
> Hi,
> In a situation like this
>
> outflow = AXIS2_OP_GET_OUT_FLOW(app_msg_op_desc, env);
> AXIS2_OP_SET_OUT_FLOW(create_seq_op, env, outflow);
>
> Simply getting and setting the arraylist like this would leave to seg
> faults
> when both operations try to free the flow. Therefore I would like to have
> a new function in utilities
>
> axis2_status_t AXIS2_CALL
> axis2_utils_array_copy(
> const axis2_env_t *env,
> const axis2_array_list_t *array_to_copy)
> {
> int size = 0, i = 0;
> axis2_array_list_t *new_array = NULL;
> if(array_to_copy)
> size = AXIS2_ARRAY_LIST_SIZE(array_to_copy, env);
> if(size > 0)
> {
> new_array = axis2_array_list_create(env, 0);
> if(!new_array)
> {
> AXIS2_ERROR_SET(env->error, AXIS2_ERROR_NO_MEMORY,
> AXIS2_FAILURE);
> return AXIS2_FAILURE;
> }
> }
> for(i = 0; i < size; i++)
> {
> void *item = AXIS2_ARRAY_LIST_GET(array_to_copy, env);
> AXIS2_ARRAY_LIST_ADD(new_array, env, item);
> }
> return new_array;
> }
>
>
> Or may be we can have this function in array_list it self
>
> 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
Re: [Axis2] Duplicating array list
Posted by Damitha Kumarage <da...@gmail.com>.
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
Re: [Axis2] Duplicating array list
Posted by Damitha Kumarage <da...@gmail.com>.
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
Re: [Axis2] Duplicating array list
Posted by Samisa Abeysinghe <sa...@gmail.com>.
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
Re: [Axis2] Duplicating array list
Posted by Damitha Kumarage <da...@gmail.com>.
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
> Damitha
>
>>
>> Samisa...
>>
>> Damitha Kumarage wrote:
>>
>>> Hi,
>>> In a situation like this
>>>
>>> outflow = AXIS2_OP_GET_OUT_FLOW(app_msg_op_desc, env);
>>> AXIS2_OP_SET_OUT_FLOW(create_seq_op, env, outflow);
>>>
>>> Simply getting and setting the arraylist like this would leave to
>>> seg faults
>>> when both operations try to free the flow. Therefore I would like to
>>> have
>>> a new function in utilities
>>>
>>> axis2_status_t AXIS2_CALL
>>> axis2_utils_array_copy(
>>> const axis2_env_t *env,
>>> const axis2_array_list_t *array_to_copy)
>>> {
>>> int size = 0, i = 0;
>>> axis2_array_list_t *new_array = NULL;
>>> if(array_to_copy)
>>> size = AXIS2_ARRAY_LIST_SIZE(array_to_copy, env);
>>> if(size > 0)
>>> {
>>> new_array = axis2_array_list_create(env, 0);
>>> if(!new_array)
>>> {
>>> AXIS2_ERROR_SET(env->error, AXIS2_ERROR_NO_MEMORY,
>>> AXIS2_FAILURE);
>>> return AXIS2_FAILURE;
>>> }
>>> }
>>> for(i = 0; i < size; i++)
>>> {
>>> void *item = AXIS2_ARRAY_LIST_GET(array_to_copy, env);
>>> AXIS2_ARRAY_LIST_ADD(new_array, env, item);
>>> }
>>> return new_array;
>>> }
>>>
>>>
>>> Or may be we can have this function in array_list it self
>>>
>>> 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
>
>
Re: [Axis2] Duplicating array list
Posted by Damitha Kumarage <da...@gmail.com>.
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?
Damitha
>
> Samisa...
>
> Damitha Kumarage wrote:
>
>> Hi,
>> In a situation like this
>>
>> outflow = AXIS2_OP_GET_OUT_FLOW(app_msg_op_desc, env);
>> AXIS2_OP_SET_OUT_FLOW(create_seq_op, env, outflow);
>>
>> Simply getting and setting the arraylist like this would leave to seg
>> faults
>> when both operations try to free the flow. Therefore I would like to
>> have
>> a new function in utilities
>>
>> axis2_status_t AXIS2_CALL
>> axis2_utils_array_copy(
>> const axis2_env_t *env,
>> const axis2_array_list_t *array_to_copy)
>> {
>> int size = 0, i = 0;
>> axis2_array_list_t *new_array = NULL;
>> if(array_to_copy)
>> size = AXIS2_ARRAY_LIST_SIZE(array_to_copy, env);
>> if(size > 0)
>> {
>> new_array = axis2_array_list_create(env, 0);
>> if(!new_array)
>> {
>> AXIS2_ERROR_SET(env->error, AXIS2_ERROR_NO_MEMORY,
>> AXIS2_FAILURE);
>> return AXIS2_FAILURE;
>> }
>> }
>> for(i = 0; i < size; i++)
>> {
>> void *item = AXIS2_ARRAY_LIST_GET(array_to_copy, env);
>> AXIS2_ARRAY_LIST_ADD(new_array, env, item);
>> }
>> return new_array;
>> }
>>
>>
>> Or may be we can have this function in array_list it self
>>
>> 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
Re: [Axis2] Duplicating array list
Posted by Dinesh Premalal <xy...@gmail.com>.
Samisa Abeysinghe <sa...@wso2.com> writes:
> I would alway prefer a reference rather than a copy - specially
I'm also +1 for reference.
thanks,
Dinesh
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org