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 Sahan Gamage <sa...@wso2.com> on 2006/02/06 06:44:04 UTC
[Axis2]Threading model in Axis2C
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
Re: [Axis2]Threading model in Axis2C
Posted by Samisa Abeysinghe <sa...@gmail.com>.
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...
>>
>>
>>
>>
>
>
>
>
Re: [Axis2]Threading model in Axis2C
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
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...
>
>
Re: [Axis2]Threading model in Axis2C
Posted by Samisa Abeysinghe <sa...@gmail.com>.
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...
Re: [Axis2]Threading model in Axis2C
Posted by Samisa Abeysinghe <sa...@gmail.com>.
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...