[Ace-users] Race condition between handle_input() & handle_timeout() in ACE_Svc_Handler ?

[ShawnQ]

Hi all ACE experts,

I'm newbie to ACE. Now I'm struggle with a nasty crash in my
application, and it's seems caused by race condition between the
handle_timout() and handle_input()

This is a service application, using ACE5.4, running under windows XP
I used TPReactor, and extended ACE_Svc_Handler to handle incoming tcp
requests.

In order to recycle/close idle connections, we also registered a timer
and in our Svc_Handler::handle_timeout(), if detected that handler is
idle, then we'll return -1 to release the handle.

But I found an interesting problem by this *timeout* mechanism, that
is, if a request come in at the *exact* time when *timeout* is fired,
ACE might crash.

To reproduce this problem, I changed the server idle timeout interval
to 5s, and write a client app to send request to server every 5s, soon
the service application crashed.
By analysising the log and call stack trace and the thread states, I
found that there seems to be a race condition.

Request -> come in -> Handler ctor called and timer is registered ->
back to the ACE -> OS Switch to another thread -> ACE trigger the
timer and spawn a new thread to call the handle_timeout on this newly
created handler -> handle_timeout return -1(detected the busy/active
state, but got idle information) -> back to ACE -> handler destructor
called -> OS switch back to the first thread -> crash...

Any ideas ? or Could anyone give me some advice about how to close the
handler gracefully & thread-safely when idle timeout is triggered ?

Many thanks,

Shawn