From: Philippe Gerum <rpm@xenomai.org>
To: NZG <metalninjadragon@domain.hid>
Cc: Jan Kiszka <jan.kiszka@domain.hid>, xenomai@xenomai.org
Subject: Re: [Xenomai-help] writing from user space through fifo problems
Date: Fri, 22 Feb 2008 09:55:42 +0100 [thread overview]
Message-ID: <47BE8E0E.7060104@domain.hid> (raw)
In-Reply-To: <200802212145.31122.ngustavson@domain.hid>
NZG wrote:
> On Thursday 21 February 2008 10:23:15 am Jan Kiszka wrote:
>> That's good. This test will also allow you to check it against
>> - more recent Xenomai (please check the Changelog for pipe-related
>> changes since 2.3.1, I bet there are a few)
>> - some other arch, specifically x86 (IIRC, there is still some Linux
>> scheduling artifact left in the I-pipe patch for blackfin, but it
>> shouldn't make a difference here - well, who knows...)
> Well, in the process of writing a simple test I kindof found the problem.
> My user space program is writing and then immediatly closing, which appears to
> destroy the data if it hasn't been read by then. Inserting a sleep between
> write and close causes it to work.
>
Yes, releasing a fildes flushes the input queue from lingering data
before closing the user-space side.
> I noticed this because my test program was working because it just so happened
> to pause until the real time task ended before closing the fd.
>
> I remember doing this before, now that it's figured out, but it's still kind
> of problematic because it doesn't appear to be possible to block on user
> space writes.
>
> Opening with O_SYNC does not cause it to block, and fsync(fd) doesn't seem to
> do anything.
O_SYNC support has to be implemented by the driver, and Xenomai
implements this for the pipe driver since 2.4-rc1. Therefore, passing
O_SYNC to open() using 2.3.1 will just lead to a nop.
anybody have any suggestions on how to know data has been
> received before closing a pipe after a write? Surely somebody's done this
> before.
>
The only way I see with 2.3.1 would be to make a non-realtime shadow
from your user-space thread (rt_task_shadow() with priority 0), then
have it pend on a Xenomai semaphore signaled by your real-time task when
it has consumed the packet.
> thanks,
> NZG
>
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>
--
Philippe.
next prev parent reply other threads:[~2008-02-22 8:55 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-21 4:58 [Xenomai-help] writing from user space through fifo problems NZG
2008-02-21 8:08 ` Jan Kiszka
2008-02-21 9:39 ` [Xenomai-help] Xenomai maximum latency ayoub zaki
2008-02-21 9:57 ` Gilles Chanteperdrix
2008-02-21 14:44 ` [Xenomai-help] writing from user space through fifo problems NZG
2008-02-21 15:23 ` Jan Kiszka
2008-02-22 2:45 ` NZG
2008-02-22 8:55 ` Philippe Gerum [this message]
2008-02-22 13:31 ` NZG
2008-02-22 9:00 ` Gilles Chanteperdrix
2008-02-22 9:19 ` Philippe Gerum
2008-02-22 9:25 ` Gilles Chanteperdrix
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=47BE8E0E.7060104@domain.hid \
--to=rpm@xenomai.org \
--cc=jan.kiszka@domain.hid \
--cc=metalninjadragon@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.