axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Damitha Kumarage <damith...@gmail.com>
Subject Re: RE : RE : Multi-threading
Date Sat, 03 Jan 2009 08:00:08 GMT
Patrick van Beem wrote:
> Hello Carl,
>  
>   
>> It sounds like you would like to free resources on a per-call basis.  Is
>> that right?  I'm quite new to the Axis2/C architecture so perhaps a more
>> experienced person could suggest a mechanism that would fit into the
>> existing methodology and provide this extra feature.  My impression is
>> that the design philosophy so far is to free resources after all calls
>> are completed.
>>     
>
> I'm only in it myself for about a month too. But you're right on the design philosophy.
Only: that's not the usage pattern of our application. We've got a (very) large client - server
application where the user can write his own code (using a custom declarative / constraint
programming language). Some interfaces available in this server programming environment perform
calls to the outside world using soap. It's up to the user when and how to use it. So our
framework must be flexible. We do not know in advance what the end-user is going to write.
> I was hoping to be able to re-use axis structures for each (parallel) call. Or cloning
them. But indeed, this is not the design philosophy of axis. I'm now on the road of using
thread local storage (TLS) to store the thread-specific structures, so I don't have to allocate
/ free them for each thread (my threads are worker threads that can do anything. Not just
soap calls. So I can't (don't want) to design them for a set of specific soap calls).
>  
>   
>>> With the fd_set in winsock and the select() function, you can wait
>>> at a maximum of 64 (current implementation) sockets at once.
>>> With I/O Completion Ports you can use one thread for an infinite
>>> number of ports... But I think they don't fit well in the modular
>>> (transportation) design of axis
>>>       
>> That's very interesting.  I'm curious as to more of the details of how
>> this functions... If you have one thread waiting on 12 sockets and want
>> to make a new call, can this thread begin the next call, or does a
>> second thread open the socket and pass the job of waiting on it to the
>> first thread? 
>>     
>
> The 'problem' is that the waiting thread can only wait on sockets. Not also on, for example,
a job queue. So the waiting thread is mostly implemented as some round-robin algorithm: Wait
on the sockets with a time-out of a few milliseconds, check a job queue and optionally perform
a few tasks (open more sockets, accept a socket another thread opened, ...) and start waiting
again on the new set of sockets. So this uses slightly more CPU then strictly necessary. The
IO completion ports use a call-back strategy when IO on a socket is completed. This is a much
nicer concept. If you're programming C++, you might be interested in the asio classes of the
boost project, where the used IO completion for their windows implementation of the asio (asynchronous
IO). But we're running out of context :-)
>
>   
>> I think we would all agree that your use case would benefit from adding
>> this capability to Axis2/C.  You mention a potential conflict with the
>> modular design of Axis; there is also the idea that making such a
>> powerful feature accessible to the average programmer using Axis could
>> be a challenge.  Maybe the solution would be to add a new communication
>> mode instead of changing all asynchronous communication to
>> one-thread-multi-socket.  I wish I understood the Axis2/C architecture
>> more fully because this would be an interesting area to contribute.  
>>     
>
> I'm not 'deep' into the details of axis too (the idea was to use an existing toolkit
to save on development time for soap, so I'm not planning to go into much detail for now either).
But one implementation might be to add another 'configuration structure' (like the allocator
and thread pool) for socket IO and make that responsible for all IO. That implementation can
then decide to use one or multiple threads for IO. It can use call-backs to signal the completion
(or failure or timeout) of the IO. The async calls can then be implemented as writing data
(by the new io struct) and exiting that start-call. Finished. Nothing more to do. No extra
thread, nothing. Then, when finished, the call-back can be used to parse the result and call
the user call-back for the result. The io struct (module) should probably use a (real!) thread
pool for this to prevent one time-consuming call to block other calls. But a simple implementation
might to for the 'average' user. This pattern mimics the io completion port / boost interface,
so users of axis can easily use these for their async IO.
>   
May be implementing a new transport using Proactor pattern(1) possibly 
using boost library is a good solution. This is possible since new 
transports could be plugged into Axis2/C by design. However this will 
need some changes in op_client implementation because currently for 
async calls it execute on new threads.
However adding this functionality through environment structure seems 
inappropriate. Also it is not clear to me how to implement it in that 
way. WDYT?.

thanks,
Damitha

[1] 
http://www.boost.org/doc/libs/1_37_0/doc/html/boost_asio/overview/core/async.html

-- 
__________________________________________________________________

Damitha Kumarage
http://people.apache.org/
__________________________________________________________________


Mime
View raw message