[Ace-users] ACE_Reactor Thread Exits

BlueJayWay sgrsgrsgr at gmail.com
Wed Nov 7 14:09:28 CST 2007

On Nov 7, 10:56 am, schm... at dre.vanderbilt.edu (Douglas C. Schmidt)
> Hi,
> >Running ACE v4.5.1 on Solaris 10
> You are using an ANCIENT version of ACE.  Please upgrade to ACE+TAO+CIAO x.6.1 (i.e., ACE 5.6.1, TAO 1.6.1, and
> CIAO 0.6.1), which you can download from
> http://download.dre.vanderbilt.edu
> under the heading: "Latest Beta Kit."
> The DOC groups at Washington University, UC Irvine, and Vanderbilt
> University only provide "best effort" support for non-sponsors for the
> latest release, as described in
> http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-bug-proc...
> Thus, if you need more "predictable" help for earlier versions of
> ACE+TAO, I recommend that you check out
> http://www.dre.vanderbilt.edu/support.html
> for a list of companies that will provide you with ACE+TAO commercial
> support.
> >We are using the ACE_Select_Reactor to manage TCP stream sockets,
> >whereby
> >we register an ACE_Event_Handler with the ACE_Reactor to handle each
> >socket
> >connection.
> >Other than the explicit -1 return from a handle_* callback method, hat
> >is the correct way to
> >subsequently inform the ACE_Reactor that we would like to close a
> >given TCP socket?
> Please see Chapter 3 of C++NPv1 <www.cs.wustl.edu/~schmidt/ACE/book1/>
> for details on how to do this.
> >Is it OK to call ACE_Reactor::instance()->remove_handler()
> >from a different thread than the thread running the ACE_Reactor event
> >loop?
> Yes, that should work fine - assuming you're using the appropriate
> type of Reactor (again, see Chapter 3 of C++NPv1 for details).
> >It seems like this causes the socket to be closed and then appears as
> >EBADF in the ACE_Reactor's select loop.  And if the associated file
> >descriptor is quickly reused (e.g. for another socket connection or
> >file),
> >then there is a window where the ACE_Reactor may get confused and exit
> >its thread
> >from within its check_handles() method.
> I recommend you upgrade..
> Thanks,
> Doug
> --
> Dr. Douglas C. Schmidt                       Professor and Associate Chair
> Electrical Engineering and Computer Science  TEL: (615) 343-8197
> Vanderbilt University                        WEB:www.dre.vanderbilt.edu/~schmidt
> Nashville, TN 37203                          NET: d.schm... at vanderbilt.edu


Thanks for the reply.  Sorry, I flubbed the ACE version info.  We are
running ACE 5.4.1, not 4.5.1.
We could upgrade to ACE 5.6 (which I assume is the latest stable
release), but is there any way
to know if this particular issue would be resolved by ACE 5.6?  Thanks
for the pointer to your
"C++ Network Programming" books, I'll definitely pick them up.

Essentially, we are invoking ACE_Reactor::instance()->remove_handler()
at some point
when we see that a given TCP stream socket has had a problem (e.g.
send fails repeatedly
with EWOULDBLOCK).  However, the remove_handler() is invoked
explicitly in a separate thread
from the thread that is running the ACE_Reactor singleton.

So we see that we get an EBADF detected by the select() call within

But if the associated fd is quickly reused, then ACE sees no problem
its check_handles().  I assume that when select() sees EBADF but
sees no problem with any fds in the set, the ACE_Reactor assumes it's
confused and exits.


More information about the Ace-users mailing list