Patrick van Beem wrote:
Hello Carl,
What Axis does well is freeing resources (once we figure out how to set
everything up right!) so I am a little confused as to where exactly the
limitations are. You say the callback system provided is not good in
terms of freeing resources, but have you tried freeing your resources
from another function which itself waits for the callback to occur?
(either error callback or success callback) I think this is the way
Axis was designed with as implied by Dimuthu: wait in a loop in your
main thread while the callbacks are outstanding, do no cleanup in the
callback itself, let that thread exit completely and after it is done,
then from your main thread detect that the callback ocurred and do the
cleanup there.
Correct. But I think the design is missing one thing. If I allocate the stub and env and then do an async call, I'm not allowed to free those two resources in the callback, because they're used by the axis framework. But if I signal the main thread from the callback, to free the resources, the callback might be switched out directly after this signal, and the main thread might free the resources before the callback ended and the axis framework used them. As you indicate, the only safe way is to wait until the thread is finished. But the axis framework does not provide an api to find out which thread is processing you request. And it shouldn't, because the thread mechanism is an implementation detail of the axis framework. Future versions might re-use the thread or even use no threading at all for asynchronous calls. So the only safe way to free resources is for the axis framework to signal the caller that the resources are no longer needed. A (second?) callback is the most used (elegant) way to do this.
Yes, this problem exists in the current implementation. A second
callback as you said is the ideal solution.
thanks,
Damitha
Right now, the framework does not provide a safe way of freeing resources in
async calls.
My reason for responding though is really to comment on this phrase:
"Threads are a rather expensive resource to use for just waiting on an
IO completion". It may be my lack of understanding, but I am pretty
sure that -- at least in the win32 tcp/ip stack -- once your thread goes
into asynchronous communication on a socket, you do not see it again
until there is some result. This means if there is a timeout your
thread is inactive for a long time.
Correct. So if I've got a couple of hundred outstanding calls, they all consume
precious memory. In our case, this is a lot of memory, since we have a heavy
server applications with a greedy memory allocation strategy per thread (for
performance) and a rather large default stacks. Of course, both can be
optimized for the 'just waiting on io-completion'-threads...
CPU-wise, it's no problem.
How can one thread wait on more
than one asychronous communication? I admit this would be a far better
solution, however from my understanding of winsock2 it is not possible.
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 (though a pool of threads
might be a good idea if the number of sockets grows large). This is also used
by the well known boost (C++) library. Mechanisms like these would be a much
better implementation. But I think they don't fit well in the modular
(transportation) design of axis, since they require knowledge about the lower
level transportation on a higher level.
Seen this way, one thread per socket communication is maybe expensive in
resources, but it is the only way to ensure your main thread continues
to operate in a timely fashion.
But prone to explode with a log of async calls. As a 'workaround' I've now my
own static-sized thread pool that perform synchronous calls. If there are more
async calls then threads in the pool, they're queued.
Thank you for your input.
--
__________________________________________________________________
Damitha Kumarage
http://people.apache.org/
__________________________________________________________________
