axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Mitchell" <>
Subject RE: Multi-threading
Date Tue, 16 Dec 2008 17:59:42 GMT
Patrick, thanks for your other note addressing Supun.  I, too, was a little
puzzled trying to understand his response, as I had not experienced any
instances of crashes/failures from double frees in Axis2c (provided I
avoided libxml).  Thinking about Supun's comments, I concluded that this
must be a difference between sync and async I/O.  From your description, the
implementation architecture I chose matches yours: a pool of threads
performing synchronous I/O.  Thus I fortuitously avoided the problem that
Carl and you ran into with asynchronous calls, and that you worked around
when you went to synchronous calls.  

Best regards,
Bill Mitchell

-----Original Message-----
From: Patrick van Beem [] 
Sent: Tuesday, December 16, 2008 6:20 AM
To: Apache AXIS C Developers List
Subject: Re: RE : Multi-threading

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


Patrick van Beem
Sr. Software engineer
T +31 (0) 73 691 07 39
F +31 (0) 73 691 07 54
M +31 (0) 06 15 01 65 83

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.

View raw message