[Ace-users] Re: [ace-bugs] Deadlock in Dev_Poll_Reactor

Johnny Willemsen jwillemsen at remedy.nl
Fri Jun 22 13:02:57 CDT 2007


Hi,

>   I'm so embarassed to say this, but I've sent a wrong patch. Here is
> the correct one.

The ACE_TOKEN_GUARD_RETURN macro seems usefull for more places, maybe move
it to a header file? Maybe add this to bugzilla so that we can more easily
track this addition?

Johnny
> 
> []s
> 
> Eider
> 
> On 6/22/07, Eider Oliveira <eider.oliveira at gmail.com> wrote:
> > Follow the new patch.
> >
> > I added the "early resume" controlled by the event_handler, as it is
> > done in TP_Reactor, as suggested, and the notification handle is not
> > excepted from the EPOLLONESHOT flag.
> >
> > The Dev_Poll_Reactor semantics now is the same as the TP_Reactor,
> > which I think is the better, as epoll is a select replacement.
> >
> > []s
> >
> > Eider
> >
> > On 6/6/07, Eider Oliveira <eider.oliveira at gmail.com> wrote:
> > > Hi Steve,
> > >
> > > On 6/6/07, Steve Huston <shuston at riverace.com> wrote:
> > > > > - added a wakeup pipe, leaving the notification pipe only for
> > > > > real notification
> > > >
> > > > Why is this necessary? If the pipe is constraining, 
> building with
> > > > ACE_HAS_REACTOR_NOTIFICATION_QUEUE resolves this. Is 
> this there some
> > > > other reason for this?
> > >
> > > Yes, this is necessary to avoid a race condition at the 
> notification
> > > queue. As the notification queue eats all pending events in
> > > handle_input, it may end "eating" some notification 
> posted after the
> > > thread handling the events has been waken, preventing the 
> epoll_wait
> > > to wake on the new notification. Changing the handle_input of the
> > > notification_handler to handle one one event at a time is 
> not good for
> > > performance.
> > >
> > > Using a different pipe eliminates the race condition and makes the
> > > wake procedure simpler and faster.
> > >
> > > >
> > > > > - added the EPOLLONESHOT flag to all READ/WRITE 
> masked handles,
> > > > except
> > > > > the notify handle
> > > >
> > > > Why not the notify handle?
> > >
> > > This one is tricky. the EPOLLONESHOT prevents the epoll 
> to notify this
> > > handle until it has been resumed at epoll_ctl. If one 
> calls the notify
> > > on the reactor when the nofity_handler is disabled, the 
> notify call
> > > will have to wait the notify_handler finish its call and the
> > > notification_pipe to be resumed.
> > >
> > > Even so, I'll make more tests on this, because after I added the
> > > wakeup_pipe this could be a weak case.
> > >
> > > > Also, this changes the concurrency behaviour of the 
> reactor to be more
> > > > along the lines of ACE_TP_Reactor. Not necessarily a 
> bad thing, but
> > > > unexpected. If this is done, I believe you'd also want 
> to look at
> > > > adding the early resume capability of ACE_TP_Reactor.
> > >
> > > As the epolll is used to overcome the select limitations, 
> I suppose
> > > it'd be better if the dev_poll_reactor behaves as the tp_reactor.
> > > Besides that, the event_handler code is much simpler for the
> > > tp_reactor behaviour.
> > >
> > > Can you point me to some explanation on the early resume?
> > >
> > > > Could you please review these issues, and also rework 
> your code to
> > > > conform to the ACE coding guidelines in
> > > > 
> http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/ACE/docs/ACE-guideline
> > > > s.html and resubmit the patch?
> > >
> > > I'll rework it to be conforming to the guide lines.
> > >
> > > []s
> > >
> > > Eider
> > >
> >
> >
> > --
> > Eider Oliveira
> >
> > Site: http://eider.eti.br
> > Blog: http://web.mac.com/eider.oliveira/iWeb/Home/Blog/Blog.html
> >
> >
> 
> 
> -- 
> Eider Oliveira
> 
> Site: http://eider.eti.br
> Blog: http://web.mac.com/eider.oliveira/iWeb/Home/Blog/Blog.html
> 



More information about the Ace-users mailing list