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

Steve Huston shuston at riverace.com
Fri Jul 27 11:09:32 CDT 2007


Hi Hal,
 
Thanks for the feedback - I've edited the comments in TP_Reactor.h to
more accurately reflect this situation - thanks very much for bringing
that up.
 
-Steve

--
Steve Huston, Riverace Corporation
Would you like ACE to run great on your platform?
See http://www.riverace.com/sponsor.htm


-----Original Message-----
From: ace-bugs-bounces at cse.wustl.edu
[mailto:ace-bugs-bounces at cse.wustl.edu] On Behalf Of Hal Black
Sent: Friday, July 27, 2007 12:18 AM
To: ace-bugs at cse.wustl.edu
Subject: Re: [ace-bugs] [ACE_TP_Reactor]: [Event_Handler
suspensionnothonoredfor handle_close]


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
<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/a53d3fb9/attachment-0001.htm


More information about the Ace-users mailing list