axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Patrick van Beem" <patrick.van.b...@quintiq.com>
Subject Re: RE : RE : Multi-threading
Date Wed, 17 Dec 2008 07:03:38 GMT
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.

This whole discussion reminds me that in my opinion, the thread pool in axis should be changed
to an API that is accepting jobs that must be performed, instead of providing threads. Threads
might not be available at that moment, which now would block the calling thread, which is
usually exactly what one does NOT want when using multi threading for asynchronous purposes...
The current pool implementation just creates new threads on the flow, and thus does not have
this problem. But that's not scalable...

Willing to help workout these concepts...

Regards,

-- 

 
Patrick van Beem
Sr. Software engineer
 
Quintiq
 
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



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.

Mime
View raw message