Dmitry Adamushko wrote:
Philippe Gerum <[EMAIL PROTECTED]> wrote on 18.11.2005 12:07:22:

 >
> > Hm.. but we still have fasync_helper(-1,file,0,&state->asyncq); which is
 > > about sending a signal and that's perfectly valid (a file::counter is
 > > not involved here). And that call may lead to re-scheduling (linux
 > > re-scheduling of course) so we can't put it in a blocked section.
 > >
 > > So the best way I see is to have something like():
 > >
 > > xnpipe_drop_user_conn()
 > > {
 > > xnlock_get_irqsave(&nklock,s);
 > >
 > > while ((holder = getq(&state->outq)) != NULL)
> > > > state->output_handler(minor,link2mh(holder),-EPIPE,state->cookie);
 > >            }
 > >
 > >        while ((holder = getq(&state->inq)) != NULL)
 > >            {
 > >            if (state->input_handler != NULL)
> > > > state->input_handler(minor,link2mh(holder),-EPIPE,state->cookie);
 > >            else if (state->alloc_handler == NULL)
 > >                xnfree(link2mh(holder));
 > >            }
 > >
 > > __clrbits(state->status,XNPIPE_USER_CONN);
 > >
 > > xnlock_put_irqrestore(&nklock,s);
 > > }
 > >
> > and call it everywhere instead of clrbits(state->status,XNPIPE_USER_CONN);
 > >
 > > This way we may be sure there are no pending messages left.
 > >
 > >
 >
 > Sounds consistent, since USER_CONN flag is semantically bound to the
 > active/inactive state
 > of the associated data queues anyway.
 >

Then a patch is enclosed.


Applied, thanks.


 > --
 >
 > Philippe.

---

Dmitry


/(See attached file: pipe.cleanup-user-conn.patch)//(See attached file: ChangeLog-diff.patch)/



--

Philippe.

Reply via email to