[Ace-users] [ace-bugs] trying to fix an ACE hang

Greg Popovitch gpy at altair.com
Fri Nov 30 10:05:24 CST 2007

Steve, I also forgot to answer about the support offer. I don't think it
will be a possibility for us, our use of ACE is somewhat marginal. I'm
really the only one using it at this time. 

I can think of two ways to work around the issue for me:

- stop making my "dequeuing" thread lower priority ... hopefully this
will prevent the ACE_WFMO_Reactor_Notify message queue from filling up.

- increasing dramatically the size of the ACE_WFMO_Reactor_Notify
message queue 

class ACE_Export ACE_WFMO_Reactor_Notify : public ACE_Reactor_Notify
  /// Constructor
  ACE_WFMO_Reactor_Notify (size_t max_notifies = 1024); // make it 100
times bigger??

Thanks again for the help,


-----Original Message-----
From: Steve Huston [mailto:shuston at riverace.com] 
Sent: Friday, November 30, 2007 10:24 AM
To: Greg Popovitch; 'Douglas C. Schmidt'
Cc: ace-bugs at cse.wustl.edu
Subject: RE: [ace-bugs] trying to fix an ACE hang

Hi Greg,

> Steve, I have not spend much time to really understand ACE 
> internals, so what follows is to be taken with a grain of salt. 


> 1/ <it's safe to just drop the write if the pipe is full>
> I would have thought that this would cause the loss of a 
> message. If not
> then this really means that the messages in the WFMO_Reactor's
> queue don't really matter, and as long as this queue is not 
> empty, there
> is no need to enqueue another message, doesn't it?

I said it's ok to drop the write to the pipe if the notifications are
queued externally to the pipe. I'd have to check the code again, but I
believe that's how the ACE_WFMO_Reactor notification mechanism works.

> 2/ it still seems to me illogical that we have to hold a lock on a
> message queue to execute a notify on the reactor. Is it because we
> worried that someone will delete the message queue before the 
> notify is executed?

The notify() was moved back under the guard protection because of some
sort of shutdown race (the ChangeLog doesn't describe more than that).
It does seem illogical (and wrong) on the face, but without studying
and analysing the situation it's hard to say what the whole story is.

> I have had termination problems as well and I think it is a
> weakness of ACE. Maybe there could be be a reference counting 
> mechanism
> on objects, so they only go away when no-one references them

On some objects, that's already available. Probably the best way to
proceed is to get hard details on a particular termination problem
scenario and then ask the list for more assistance. Or take advantage
of support services ;-)

Best regards,

Steve Huston, Riverace Corporation
Want to take ACE training on YOUR schedule?
See http://www.riverace.com/training.htm

More information about the Ace-users mailing list