From: Philippe Gerum <rpm@xenomai.org>
To: NZG <ngustavson@domain.hid>
Cc: xenomai@xenomai.org
Subject: Re: [Xenomai-help] writing from NRT to a rt_pipe-> easy wait for completion
Date: Fri, 08 Jun 2007 00:44:12 +0200 [thread overview]
Message-ID: <1181256253.4998.217.camel@domain.hid> (raw)
In-Reply-To: <200706071709.03430.ngustavson@domain.hid>
On Thu, 2007-06-07 at 17:09 -0500, NZG wrote:
> On Thursday 07 June 2007 3:14 pm, Philippe Gerum wrote:
> > On Thu, 2007-06-07 at 14:46 -0500, NZG wrote:
> > > > Yes, clearly.
> > >
> > > Ah, that in conjunction with the
> > > "can't use message pipe - Cannot allocate memory"
> > > thread resolves my issues then.
> > >
> > > My assumption was that data would exist in the pipe after the write until
> > > the pipe was destroyed, irrespective of the "openness" of the NRT side.
> >
> > Nope, as a general rule, the read-side of an endpoint is flushed when
> > the other end closes. Then, you have also to take into account the
> > priority of the thread waiting on the endpoint wrt the priority of the
> > one which closes the other side.
> So, if I wanted to use standard NRT calls in user space to wait for data to
> actually be delivered through the rt pipe before closing the fd, what would
> be the best method? Select? Or is there a simple call for this I'm missing?
select() is supported, but it won't allow you to wait for the output
queue from the NRT-side to drain, it will only allow you to wait for
messages sent from the RT endpoint.
There is no simple call, I'm afraid. One way would be to make your RT
side always wait on the read-side (and process the messages as they
arrive); since the RT receiver would always have precedence over the NRT
sender, you would have the guarantee that all the messages sent have
been consumed before the NRT side closes its endpoint.
Another simple way would be to extend the pipe driver in order to
provide a new ioctl() function, returning the status of the RT input
queue, in which case, you would just have to loop issuing this ioctl()
until it reports that the RT side has consumed all the pending messages.
Not pretty, but would work.
The best way would be to extend our support for select(), in the poll
method the message pipe driver provides.
>
> thx,
> NZG
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
--
Philippe.
next prev parent reply other threads:[~2007-06-07 22:44 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-07 18:57 [Xenomai-help] writing from NRT to a rt_pipe NZG
2007-06-07 19:13 ` NZG
2007-06-07 19:34 ` Philippe Gerum
2007-06-07 19:46 ` NZG
2007-06-07 19:51 ` NZG
2007-06-07 20:14 ` Philippe Gerum
2007-06-07 20:41 ` NZG
2007-06-07 22:09 ` [Xenomai-help] writing from NRT to a rt_pipe-> easy wait for completion NZG
2007-06-07 22:44 ` Philippe Gerum [this message]
2007-06-07 22:57 ` NZG
2007-06-07 19:33 ` [Xenomai-help] writing from NRT to a rt_pipe Philippe Gerum
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1181256253.4998.217.camel@domain.hid \
--to=rpm@xenomai.org \
--cc=ngustavson@domain.hid \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.