On Mon, 2010-06-14 at 16:52 +0200, stephane ancelot wrote:
> Le Thu, 03 Jun 2010 16:35:50 +0200, Andreas Glatz
> <andreasgl...@ruggedcom.com> a écrit:
> > On Thu, Jun 03, 2010 at 04:09:38AM -0400, stephane ancelot wrote:
> >> Hi,
> >> tryied in v2.4.10 :
> >> I have opened a /dev/rtp7 pipe , and deleted it.
> >> if I launch again the same program, rt_pipe_open replies with -EBUSY
> >> ....
> > Can you describe the sequence how you are invoking
> > rt_pipe_open()/open()/rt_pipe_delete()?
> > If the following description applies to you then you discovered what
> > we've discovered
> > before and there is no easy fix for that as far as I know.
> > 1) create pipe with rt_pipe_open()
> > 2) connect to it by opening /dev/rtp7 with open()
> > 3) delete pipe with rt_pipe_delete() (for example by killing the Xenomai
> > application)
> > 4) create same pipe again with rt_pipe_open() (for example by restarting
> > the
> > Xenomai application with /dev/rtp7 is still open)
> > --> rt_pipe_open() reports an error
> Yes, but it has worked in xeno 2.1 ....
2.1 was utterly broken wrt pipe session handling, it did not work, at
all. It just created opportunities to trash your kernel memory badly
upon rt-side closure, by allowing userland to work on a deallocated pipe
while in a race window.
Now both ends are in sync, and the rt-pipe is allowed to linger until
userland is really done with it, i.e. when it has closed its endpoint.
You will get -EBUSY on the rt-side until that point is reached.
> Is there a work around ? only
> hacking it ?
Fix your app on the userland side. It should receive a zero-length read
upon rt-side closure. You just need to check for this, then close this
endpoint and reopen it right after if need be.
> Best Regards
> > Andreas
> Xenomai-core mailing list
Xenomai-core mailing list