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

[Steve Huston]

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. 

Ok.

> 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
message
> 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
are
> 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
anymore?

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

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