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...
