[ace-users] cancel_timer & handle_timeout behavior

[Colon Carlos]

No PRF since this is a general ACE question:

If I schedule a timer which it then expires and is dispatched so that
now that thread is actively executing handle_timeout(), what happens if
another thread tries to cancel this timer? Does it succeed and returns
1 or does it fail?

Thanks
Carlos

[Douglas C. Schmidt]

Hi Carlos,

> No PRF since this is a general ACE question:

Please ALWAYS use the PRF...

> If I schedule a timer which it then expires and is dispatched so that
> now that thread is actively executing handle_timeout(), what happens if
> another thread tries to cancel this timer? Does it succeed and returns
> 1 or does it fail?

The answer to this question depends on which Reactor you are using
(e.g., ACE_Select_Reactor, ACE_TP_Reactor, ACE_WFMO_Reactor) and how
you're running the reactor (e.g., in multiple threads, on Windows, etc).
Please use the PRF and reask the question.

thanks,

Doug

[Colon Carlos]

OK, here it goes:

    ACE VERSION: 5.4

    HOST MACHINE and OPERATING SYSTEM:
        Redhat Linux AS3.0

    DOES THE PROBLEM AFFECT:
        EXECUTION

    SYNOPSIS:
        Behavior of thread doing cancel_timer() when another thread is currently executing handle_timeout() on the timer.

    DESCRIPTION:

 If I schedule a timer which it then expires and is dispatched so that
 now that thread is actively executing handle_timeout(), what happens
 if another thread tries to cancel this timer?  Does it succeed and

 returns 1 or does it fail? As far as what reactor I'm using hmm that's a good
Question.  How do I tell?  I'm doing the calls as follows:

        Thread 1:
        long lTimerId =ACE_Reactor::instance()->schedule_timer(
        this,
        somedata,
        ACE_Time_Value( lDelaySecs, lDelayMicroSecs ),
        ACE_Time_Value::zero
        );

                This thread is currently dispatching the timer in handle_timeout()

        Thread 2:
        int i = ACE_Reactor::instance()->cancel_timer(
                lTimerId, (const void**)&somedata );

                        Does this thread succeed in canceling the timer that's being dispatched above?

Thanks
Carlos

[Douglas C. Schmidt]

Hi Carlos,

> OK, here it goes:

Great, thanks!

> ACE VERSION: 5.4
>
> HOST MACHINE and OPERATING SYSTEM:
> Redhat Linux AS3.0
>
> DOES THE PROBLEM AFFECT:
> EXECUTION
>
> SYNOPSIS:
> Behavior of thread doing cancel_timer() when another thread is currently executing handle_timeout() on the timer.
>
> DESCRIPTION:
>
> If I schedule a timer which it then expires and is dispatched so that
> now that thread is actively executing handle_timeout(), what happens
> if another thread tries to cancel this timer? Does it succeed and
> returns 1 or does it fail? As far as what reactor I'm using hmm that's a good
> Question. How do I tell?

You should be using ACE_Select_Reactor in this case since that's the
default on Linux.

> I'm doing the calls as follows:
>
> Thread 1:
> long lTimerId =ACE_Reactor::instance()->schedule_timer(
> this,
> somedata,
> ACE_Time_Value( lDelaySecs, lDelayMicroSecs ),
> ACE_Time_Value::zero
> );
>
> This thread is currently dispatching the timer in handle_timeout()
>
> Thread 2:
> int i = ACE_Reactor::instance()->cancel_timer(
> lTimerId, (const void**)&somedata );
>
> Does this thread succeed in canceling the timer that's being dispatched above?

If the dispatch is taking place then the timer shouldn't be cancelled
until after the handle_timeout() finishes running.

Take care,

Doug

[Colon Carlos]

Thanks for the quick reply.

When you say:

"If the dispatch is taking place then the timer shouldn't be cancelled
until after the handle_timeout() finishes running."

When you say "shouldn't" do you mean:

(a) that my logic should somehow detect that the timer is currently in
handle_timeout() processing and my logic shouldn't attempt to call
cancel_timer() in this state (perhaps by using a mutex?)
or
(b) that ACE won't allow the cancel_timer() call (either it will block
or return failure) while the timer is currently in handle_timeout()
processing.

[Douglas C. Schmidt]

Hi Carlos,

> When you say:
> "If the dispatch is taking place then the timer shouldn't be cancelled
> until after the handle_timeout() finishes running."
>
> When you say "shouldn't" do you mean:
>

> (a) that my logic should somehow detect that the timer is currently in
> handle_timeout() processing and my logic shouldn't attempt to call
> cancel_timer() in this state (perhaps by using a mutex?)
>
> or
>
> (b) that ACE won't allow the cancel_timer() call (either it will block
> or return failure) while the timer is currently in handle_timeout()
> processing.

I believe it's (b).

Thanks,

Doug

[Leon Mergen]

On 1/30/07, Douglas C. Schmidt <sch...@dre.vanderbilt.edu> wrote:

> No PRF since this is a general ACE question:

Please ALWAYS use the PRF...

Just a suggestion, since a lot of people seem to refrain from using the PRF: maybe it might be an idea to stop calling it the /problem/ report form if you also want it to be used for non-problems, and just call it something more generic, perhaps just Report Form ?

I think a lot of people might think "yeah, I should use the problem report form, but this isn't a problem, it's just a question" and be not using the PRF for that reason,

Just my 2 cents...

--
Leon Mergen
http://www.solatis.com

[Colon Carlos]

ACE VERSION: 5.4 
 
HOST MACHINE and OPERATING SYSTEM: 
     Redhat Linux AS3.0 

DOES THE PROBLEM AFFECT:
        EXECUTION 

SYNOPSIS:

        ACE_Reactor::run_event_loop()  exits unexpectedly.

DESCRIPTION:

ACE_Reactor::run_event_loop()  exits unexpectedly during a load.   If the main thread (which is running this loop) is held hostage somewhere in the process and is not able to process this loop for some time does this cause the run_event_loop to exit?

 

Thanks

Carlos

[Steve Huston]

Hi Carlos,

 

Thanks for the PROBLEM-REPORT-FORM, abbreviated though it is ;-)

 

No, a delayed callback method would not cause the loop to end prematurely. Something else is going wrong.

 

-Steve

--
Steve Huston, Riverace Corporation
New Support options to help you with ACE!
See http://www.riverace.com/support.htm

[Colon Carlos]

So upon further investigation somewhere an errno=9 is being generated (Bad File Descriptor) somehow causing the reactor event loop to exit.  I'm assuming this is in the socket processing where my client is using ACE_Connector<CONN, ACE_SOCK_CONNECTOR> where CONN is defined as ACE_Svc_Handler<ACE_SOCK_STREAM, ACE_MT_SYNCH>.  We're doing a test where we take the server down every so often to make sure the client behaves.  Any ideas what or why this error may be getting generated?  Any ideas as to why the reactor event loop is exiting upon this error getting generated?  Do I need to somehow handle this event within my service handler?  How?

 

Thanks

Carlos

---

From: Steve Huston [mailto:shu...@riverace.com]
Sent: Tuesday, February 13, 2007 11:57 AM
To: Colon Carlos; ace-...@cse.wustl.edu
Subject: RE: [ace-users] ACE_Reactor::run_event_loop() behavior

[Kobi Cohen-Arazi]

On 2/15/07, Colon Carlos <Carlos...@comverse.com> wrote:

So upon further investigation somewhere an errno=9 is being generated (Bad File Descriptor) somehow causing the reactor event loop to exit.  I'm assuming this is in the socket processing where my client is using ACE_Connector<CONN, ACE_SOCK_CONNECTOR> where CONN is defined as ACE_Svc_Handler<ACE_SOCK_STREAM, ACE_MT_SYNCH>.  We're doing a test where we take the server down every so often to make sure the client behaves.  Any ideas what or why this error may be getting generated?  Any ideas as to why the reactor event loop is exiting upon this error getting generated?  Do I need to somehow handle this event within my service handler?  How?

You might want to check if you close that fd (Somewhere in the Event_Handler) but still using it in the reactor. That's one of the reasons that cause select() to return BAD FD.

HTH,
Kobi.

 

_______________________________________________
ace-users mailing list
ace-...@mail.cse.wustl.edu
http://mail.cse.wustl.edu/mailman/listinfo/ace-users

--
- Kobi
"Every problem can be solved by having another level of indirection"
      __    
    /     \  
   O /\ O
<|    \/   |>
    \ ..../

[Steve Huston]

Hi Carlos,

 

Thanks for the additional info. I did make a fix to the area of the reactor that deals with weeding out bad handles, avoiding the need to exit the event loop with EBADF. This was done after 5.4 was released - the fix is in Riverace's 5.4a as well as in the standard 5.5 and later.

 

Fri Apr  9 16:07:33 2004  Steve Huston  <shu...@riverace.com>

 

 * ace/Select_Reactor_T.cpp (check_handles): The previous method of
   locating handles to check -- iterating the handler repository for
   ACE_Event_Handler pointers and calling get_handle() -- didn't work
   if the handler didn't do get_handle() as we expected. Changed this
   to build a union of the read/write/exception wait_set masks and
   iterate through that. If a bad handle is found, call
   remove_handler_i() based on the handle, not the event handler
   pointer.

Without studying the code in question it's difficult to say if this fix is something that would help your application, but it's possible. If you need/want to stay at ACE 5.4, then 5.4a is a good option - you can find it on www.riverace.com via the "Downloads" link at the top of the page.

 

If you can transition to ACE 5.5, that also has the same fix.

 

Best regards,

-Steve

--
Steve Huston, Riverace Corporation
New Support options to help you with ACE!
See http://www.riverace.com/support.htm

-----Original Message-----
From: Colon Carlos [mailto:Carlos...@comverse.com]
Sent: Thursday, February 15, 2007 1:21 PM
To: Steve Huston; ace-...@cse.wustl.edu
Subject: RE: [ace-users] ACE_Reactor::run_event_loop() behavior

So upon further investigation somewhere an errno=9 is being generated (Bad File Descriptor) somehow causing the reactor event loop to exit.  I'm assuming this is in the socket processing where my client is using ACE_Connector<CONN, ACE_SOCK_CONNECTOR> where CONN is defined as ACE_Svc_Handler<ACE_SOCK_STREAM, ACE_MT_SYNCH>.  We're doing a test where we take the server down every so often to make sure the client behaves.  Any ideas what or why this error may be getting generated?  Any ideas as to why the reactor event loop is exiting upon this error getting generated?  Do I need to somehow handle this event within my service handler?  How?

 

[Colon Carlos]

Hi Steve, thanks for the info.  Is it OK then to restart the event loop if we get such an error?  If so, should I recycle the Service_Handler/Connection?  Or will that still run OK without recycling as long as I restart the event loop?

 

Thanks

Carlos

---

From: Steve Huston [mailto:shu...@riverace.com]

Sent: Thursday, February 15, 2007 1:45 PM

[Steve Huston]

Hi Carlos,

 

If there's a bad handle registered with the reactor and you restart the event loop, it'll probably just exit right away after seeing the same bad handle. You have to somehow find and remove the bad handle.

[Colon Carlos]

Thanks, Again.  Before I decide what approach to take here, is there a bad handle registered because my logic is somehow faulty?  I'm trying to figure out if there's something in my logic I can change to not cause the bad handle registration with the reactor in the first place.  The logic works ok (in live sites:) under normal conditions and in most abnormal conditions.  We're just trying to get that extra 9 of reliability here:-)  Is there a particular strategy of detecting a registered bad handle?

 

Thanks

Carlos

---

From: Steve Huston [mailto:shu...@riverace.com]

Sent: Thursday, February 15, 2007 2:33 PM

[Matthew Gillen]

Colon Carlos wrote:
>
> Thanks, Again. Before I decide what approach to take here, is there a
> bad handle registered because my logic is somehow faulty? I'm trying to
> figure out if there's something in my logic I can change to not cause
> the bad handle registration with the reactor in the first place. The
> logic works ok (in live sites:) under normal conditions and in most
> abnormal conditions. We're just trying to get that extra 9 of
> reliability here:-) Is there a particular strategy of detecting a
> registered bad handle?

You could try to read from it, and check the return value / errno (you might
try to read zero bytes, but I'm not sure that would work, or if it's portable).

Matt

[Steve Huston]

Hi Carlos,

 

The usual reason a EBADF comes up in the reactor is because a valid handle was registered and subsequently closed without telling the reactor about it.

 

-Steve

--
Steve Huston, Riverace Corporation
New Support options to help you with ACE!
See http://www.riverace.com/support.htm

-----Original Message-----
From: Colon Carlos [mailto:Carlos...@comverse.com]
Sent: Thursday, February 15, 2007 3:28 PM
To: Steve Huston; ace-...@cse.wustl.edu
Subject: RE: [ace-users] ACE_Reactor::run_event_loop() behavior

Thanks, Again.  Before I decide what approach to take here, is there a bad handle registered because my logic is somehow faulty?  I'm trying to figure out if there's something in my logic I can change to not cause the bad handle registration with the reactor in the first place.  The logic works ok (in live sites:) under normal conditions and in most abnormal conditions.  We're just trying to get that extra 9 of reliability here:-)  Is there a particular strategy of detecting a registered bad handle?