ace_reactor::schedule_timer,cancel_timer thread safe?

[sunil]

Hi,
I have a server that creates multiple ACE tasks and uses ACE Reactor.
Main thread does ACE_Reactor::instance()->run_reactor_event_loop();
while other threads do processing. From multiple threads/tasks, I am
calling ACE_Reactor::instance()->schedule_timer/cancel_timer. Are
these methods thread safe? I dont initialize ACE_Reactor in any
special way (so I assume its what ever default reactor is).
Environment info:
ace_version:5.4.2
platform: SUN SOLARIS SunOS 5.10 Generic_127111-09 sun4u
sparc SUNW,Sun-Fire
C++ compiler:CC: Sun C++ 5.5 Patch 113817-12 2005/03/08
Thanks Much,
Sunil

[Douglas C. Schmidt]

Hi Sunil,

> I have a server that creates multiple ACE tasks and uses ACE Reactor.
>Main thread does ACE_Reactor::instance()->run_reactor_event_loop();
>while other threads do processing. From multiple threads/tasks, I am
>calling ACE_Reactor::instance()->schedule_timer/cancel_timer. Are
>these methods thread safe?

Yes, they should be thread-safe, modulo any bugs that were part of
such an old version of ACE.

Doug

> I dont initialize ACE_Reactor in any
>special way (so I assume its what ever default reactor is).
>Environment info:
> ace_version:5.4.2
> platform: SUN SOLARIS SunOS 5.10 Generic_127111-09 sun4u
>sparc SUNW,Sun-Fire
> C++ compiler:CC: Sun C++ 5.5 Patch 113817-12 2005/03/08
>Thanks Much,
>Sunil

--
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.sc...@vanderbilt.edu

[Douglas C. Schmidt]

Hi Rajeev,

Thanks very much for your email. Please make sure to send all
questions related to TAO or ACE to the ACE mailing list or ACE+TAO
newsgroup, rather than to me directly since I travel frequently and
often don't have ready access to email.

> Just wanted to comment here. I've found that when using Dev_Poll
> Reactor and handlers created via Acceptor/Connector classes that
> trying to close the peer_ object within handle_timeout() causes the
> process to core dump.

A couple thoughts here:

. The original question was about the ACE_Reactor on Solaris, which
defaults to the ACE_Select_Reactor, not the ACE_Dev_Poll_Reactor.

. Please use the PRF so that we know what version of ACE et al. you're
referring to.

> Its possible that I'm approaching this the wrong way (still scratching my head), but I don't think the contained ACE_SOCK_Stream objects are thread safe.

That's correct - ACE_SOCK_Stream objects are not thread safe.

> I'm trying to use the timer mechanism to implement a timeout process which will close the socket resource when the client/server takes too long to respond.
>
> Unfortunately, I can't give you a core file as my system runs under JNI and cannot produce core dumps. However I do know that the crash occurs in ACE::recv_n_i or ACE::send_n (or somewhere down the line).
>
> At present, my work around is to not use the timer mechanism to close the resource. This does ultimately lead to a slow leak of handlers that are waiting on non-responsive connections.
>
> Do you have any advice with regards to this ?

Sure, you could switch to an ACE_Select_Reactor-based approach, which is
more stable than the ACE_Dev_Poll_Reactor. Conversely, you could
contact one of the ACE commercial support companies listed at

http://www.dre.vanderbilt.edu/support.html

to see if they can provide you help with your design and/or improve the ACE_Dev_Poll_Reactor.

Thanks,

Doug

[Steve Huston]

It sounds like you should be investigating the use of event handler
reference counting to ensure your handler doesn't get destroyed out from
under a callback.

Please see http://www.riverace.com/newsletters/October2005.htm for an
article explaining this.

-Steve

--
Steve Huston, Riverace Corporation
Total Lifecycle Support for Your Networked Applications
http://www.riverace.com

> _______________________________________________
> ace-users mailing list
> ace-...@list.isis.vanderbilt.edu
> http://list.isis.vanderbilt.edu/mailman/listinfo/ace-users
>