Mailing-List: contact axis-c-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-Id: <4961CEB8.6E68.0040.0@quintiq.com>
Date: Mon, 05 Jan 2009 09:11:22 +0100
From: "Patrick van Beem" <patrick.van.beem@quintiq.com>
To: "Apache AXIS C Developers List" <axis-c-dev@ws.apache.org>
Subject: Re: Multi-threading
References: <08CEB0908629C64AB48367CEF2DD012901B1E4D3@smmtl102.axa.ca>
 <007e01c95bb7$27944120$76bcc360$@rr.com>
 <4947ACA6.6E68.0040.0@quintiq.com> <495F1B25.3080507@gmail.com>
In-Reply-To: <495F1B25.3080507@gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hello,
--=20

=20
Patrick van Beem
Sr. Software engineer
=20
Quintiq
=20
T +31 (0) 73 691 07 39
F +31 (0) 73 691 07 54
M +31 (0) 06 15 01 65 83
E patrick.van.beem@quintiq.com
I www.quintiq.com


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

No. The current implementation of axis relies on an infinite number of =
available threads. It assumes that when it requests a thread, it's getting =
one and it then starts the thread with a thread method / data. But in =
reality, a thread pool would have a finite number of (re-used) threads. In =
the case of axis, this would mean that the thread requesting the new =
thread would block until a new thread is available. This is not what you =
want. For axis to work with  a finite number of threads, the way it uses =
threads should change. It should not request a thread, but it should =
submit a job (probably the thread method and data) to the thread pool. The =
submitting thread can then continue an the thread pool can decide when the =
job is performed by which thread.

Regards,


Quintiq Conference "Quintessence 09" Tuesday May 12th, 2009, Country =
Estate Duin & Kruidberg, near Amsterdam Schiphol, The Netherlands - for =
more information visit www.quintiq.com

This message contains information that may be privileged or confidential =
and is the property of Quintiq. It is only intended for the person to whom =
it is addressed. If you are not the intended recipient, you are not =
authorized to read, print, retain, copy, disseminate, distribute or use =
this message or any part thereof. If you have received this message in =
error, please notify the sender immediately and delete all copies of this =
message. Please note that e-mails are susceptible to change, therefore =
they are not binding.