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