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: Multi-threading
Date Sat, 03 Jan 2009 08:00:37 GMT
Patrick van Beem wrote:
> Hello Bill
>
>   
>> Patrick, when building a multi-threaded Axis2C client I too was 
>> concerned about the multiple environments.  Although your 
>> statement is correct in a sense that each thread needs its own 
>> environment/stub, these environments can in fact share much of 
>> the underlying structures.  In practice, each thread needs its 
>> own error stack, but it can certainly share the allocator and 
>> logger.  And the configuration information is associated with 
>> the allocator.  There is a primitive function 
>> axutil_env_create_with_error_log_thread_pool() that lets you 
>> share the substructures already created for the "global" environment 
>> created once for the application.  This way the configuration 
>> information is read only once.  Axutil_env_free_masked() lets 
>> each thread free just its error stack upon termination, leaving 
>> the allocator et.al. intact.  
>>     
>
> Correct. I already use these. But afaik the configuration file is read when creating
the stub. And that should be done for each thread / call. So while many resources can indeed
be shared, the one needing the most (time-consuming) initialization (I think), can't. I think
this would be a great improvement for the future.
>   
I think adding this functionality to the stub creation is straight 
forward. Just add the stub creation function
axis2_stub_create_with_conf_ctx_and_endpoint_ref_and_client_home(const 
axutil_env_t * env, axis2_conf_ctx_t *con_ctx, axis2_endpoint_ref_t * 
endpoint_ref, const axis2_char_t * client_home));

which in turn call already available api function

axis2_svc_client_create_with_conf_ctx_and_svc(
        const axutil_env_t * env,
        const axis2_char_t * client_home,
        axis2_conf_ctx_t * conf_ctx,
        axis2_svc_t * svc);

>   
>> I was not dealing with asynchronous operation in my application, 
>> so I don't know if you might need a separate thread-pool for 
>> each created environment.  
>>     
>
> The current implementation of a thread pool in axis is no thread pool but a collection
of thread creation and deletion methods... So no...
>   
But when creating environment you can pass your own thread pool. Would 
that not help?
thanks,

thanks,
Damitha
> Thank you for your input.
>
>   


-- 
__________________________________________________________________

Damitha Kumarage
http://people.apache.org/
__________________________________________________________________

Mime
View raw message