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