[Ace-users] Re: [ace-bugs] [ACE_TP_Reactor]: [Event_Handler suspension nothonoredfor handle_close]

[Hal Black]

Thanks Doug, Johnny, and Steve all for your quick replies.

On 7/26/07, Steve Huston <shuston at riverace.com> wrote:
>
> Hi folks,
>
> As Doug and Johnny indicated, there were some important improvements
> to ACE_TP_Reactor a few betas ago, and 5.5.9 may resolve this. But I
> want to clarify a question Hal asked:
>
> >       As I understand it, the ACE_TP_Reactor is supposed to
> > suspend events
> > on an event handler that is being called by another thread
> > until that call
> > returns.  So what's going on here?  Is this a mistaken
> > interpretation by me?
>
> Yes, a common one... ACE_TP_Reactor suspends the handler around _I/O_
> callbacks, but not around notifies or timers. Since you're using
> notify(), the suspension around your handle_input() callback is
> ineffective.


Ahh, so that's why it looked like it didn't suspend notifies, timers, etc
when I was reading through the ACE_TP_Reactor source code.  I just couldn't
fathom how the ACE_TP_Reactor would be useful at all without the locking:
there would be no safe way for general purpose event handlers being called
by the TP Reactor to self destruct (which is very widely used with
ACE_Event_Handlers).  You guys do such a great and thorough job, I just
assumed I was missing something.  8')

The reference-counted event handler sounds like it will solve that problem,
though.  I really should go through the back issues of the Riverace
newsletters, huh?

Changing this comment from ACE_TP_Reactor.h might make this misconception a
bit less common, still:

 *  [...] Note that callback code in
 * Event Handlers (e.g. Event_Handler::handle_input) does not have to
 * be modified or made thread-safe for this Reactor.  This is because
 * an activated Event Handler is suspended in the Reactor before the
 * upcall is made and resumed after the upcall completes.  Therefore,
 * one Event Handler cannot be called by multiple threads
 * simultaneously.


> Is there a known bug in this version?  Or is something else
> > entirely going on?
>
> You may also want to investigate using reference-counted event
> handlers, which would prevent deletion of the handler while there's a
> notify() queued, or any timer or I/O registrations still in effect.
> This is covered in the October 2005 edition
> (http://www.riverace.com/newsletters/October2005.htm) of the Riverace
> ACE News and Tips newsletter.


Great tip.  Is ACE_Svc_Handler::handle_close() is safe to call?  That is,
does it know about the reference counting and therefore won't self destruct
and mess up the reference counting scheme?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://list.isis.vanderbilt.edu/pipermail/ace-users/attachments/20070727/94a822f9/attachment-0001.htm