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]Threading model in Axis2C
Date Mon, 06 Feb 2006 12:35:54 GMT
There are two interesting calsses in JDK 1.5 java.util.concurrent
ThreadPoolExecutor and ThreadFactory. They both deal with Thread class.

I think, in our case, the specific thread implementation implementing 
our thread abstraction API can look after the ThreadPoolExecutor and 
ThreadFactory like functionality. What we would be interested in the 
core engine, where erver threads are to be used, is the Thread class 
like API IMHO. For out reqirement that would do, I suppose.

Samisa...

Sanjiva Weerawarana wrote:

>Another option to look at might be the JDK 1.5 java.util.concurrent
>package's thread pool stuff ..
>
>Sanjiva.
>
>On Mon, 2006-02-06 at 12:57 +0600, Samisa Abeysinghe wrote:
>  
>
>>Samisa Abeysinghe wrote:
>>
>>    
>>
>>>Sahan Gamage wrote:
>>>
>>>      
>>>
>>>>Hi,
>>>>
>>>>I am having some design issues with the threading model in Axis2.
>>>>According to the design and the current implemented code base we need an
>>>>abstracted threading model in the axis2 core modules. But I am currently
>>>>having some doubts about defining this threading model.
>>>>The problem with using a very high level thread pool is the inablity to
>>>>control the behaviour of the thread by the creater. Example is :
>>>>In the thread pool we have a function to execute a function inside a 
>>>>thread:
>>>>
>>>>thread_pool_execute(thread_pool_t, worker_function);
>>>>
>>>>Inside the axis2_http_server, for a new request we create a worker and
>>>>ask the thread pool to excute the run function.
>>>>axis2_status_t handle_request(...)
>>>>{
>>>>   axis2_http_worker_t worker;
>>>>   ...
>>>>   axis2_thread_pool_execute(thread_pool, worker->run);
>>>>}
>>>>
>>>>The problem in this approach is the caller can't control the behaviour
>>>>of the thread which excutes the "run" function. Only the thread pool has
>>>>the control of it.
>>>>So my suggestion is we can do the same thing as what we did to the
>>>>allocator. The thread_manager is just an api which contains creation,
>>>>destroying and other control mechanisms for the threads. So the above
>>>>code will look like:
>>>>
>>>>axis2_status_t handle_request(...)
>>>>{
>>>>   axis2_http_worker_t worker;
>>>>   ...
>>>>   axis2_thread_t *req_thread  =
>>>>AXIS2_THREAD_CREATE(env->thread_manager, worker->run, ...);
>>>>   /* after the execution */
>>>>   AXIS2_THREAD_CANCEL(env->thread_manager, *req_thread ....);
>>>>}
>>>>
>>>>In this way the caller has much more control over the created thread as
>>>>well as we have the freedom to implment the threading model in our own
>>>>way. Only thinng required is to implement the API specified in the
>>>>axis2_thread_manager.
>>>>
>>>>Pls feel free to comment.
>>>>
>>>>- Sahan
>>>>
>>>> 
>>>>
>>>>        
>>>>
>>>In my understanding, this proposed model is OK. A thread pool is for 
>>>managing the creation of threads. Thus, if one wants a thread pool, 
>>>(s)he can hide the pool behind thread_create function. Additionally, 
>>>looking at APR and NSPR, it does not look like they provide a thread 
>>>pool API, rather a thread API, hence this proposal leaves room to 
>>>allow plugging in such APIs for thread support without problem.
>>>
>>>Samisa...
>>>
>>>      
>>>
>>As of now, if we have support for
>>1. thread_create
>>2. thread_join
>>3. thread_detach
>>4. thread_data
>>that would be sufficient. (I had a look into APR and NSPR, they have 
>>provision for those)
>>We can implement the rest as and when required.
>>
>>Samisa...
>>
>>
>>    
>>
>
>
>  
>


Mime
View raw message