[Ace-users] ACE_Reactor Thread Exits

[BlueJayWay]

On Nov 7, 10:56 am, schm... at dre.vanderbilt.edu (Douglas C. Schmidt)
wrote:
> 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

Doug:

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
ACE_Select_Reactor_T<ACE_SELECT_REACTOR_TOKEN>::wait_for_multiple_events().

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

  Thanks