Thanks Doug, Johnny, and Steve all for your quick replies.<br><br><div><span class="gmail_quote">On 7/26/07, <b class="gmail_sendername">Steve Huston</b> <<a href="mailto:shuston@riverace.com">shuston@riverace.com</a>> wrote:
</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi folks,<br><br>As Doug and Johnny indicated, there were some important improvements
<br>to ACE_TP_Reactor a few betas ago, and 5.5.9 may resolve this. But I<br>want to clarify a question Hal asked:<br><br>> As I understand it, the ACE_TP_Reactor is supposed to<br>> suspend events<br>> on an event handler that is being called by another thread
<br>> until that call<br>> returns. So what's going on here? Is this a mistaken<br>> interpretation by me?<br><br>Yes, a common one... ACE_TP_Reactor suspends the handler around _I/O_<br>callbacks, but not around notifies or timers. Since you're using
<br>notify(), the suspension around your handle_input() callback is<br>ineffective.</blockquote><div><br>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')
<br><br>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?<br></div><br>Changing this comment from ACE_TP_Reactor.h might make this misconception a bit less common, still:
<br><br> * [...] Note that callback code in<br> * Event Handlers (e.g. Event_Handler::handle_input) does not have to<br> * be modified or made thread-safe for this Reactor. This is because<br> * an activated Event Handler is suspended in the Reactor before the
<br> * upcall is made and resumed after the upcall completes. Therefore,<br> * one Event Handler cannot be called by multiple threads<br> * simultaneously.<br><br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> Is there a known bug in this version? Or is something else<br>> entirely going on?<br><br>You may also want to investigate using reference-counted event<br>handlers, which would prevent deletion of the handler while there's a
<br>notify() queued, or any timer or I/O registrations still in effect.<br>This is covered in the October 2005 edition<br>(<a href="http://www.riverace.com/newsletters/October2005.htm">http://www.riverace.com/newsletters/October2005.htm
</a>) of the Riverace<br>ACE News and Tips newsletter.</blockquote><div><br>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?
<br></div><br></div>