From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Peter Soetens <peter@domain.hid>
Cc: Xenomai core <Xenomai-core@domain.hid>
Subject: Re: [Xenomai-core] [Xenomai-help] select: native tasks with posix skin mqueues
Date: Thu, 01 Oct 2009 16:47:59 +0200 [thread overview]
Message-ID: <4AC4C11F.2030806@domain.hid> (raw)
In-Reply-To: <634c78ce0910010730t29137af8w95b63ae21183b52b@domain.hid>
Peter Soetens wrote:
> Hi,
>
> I'm creating my RT threads using the native API and I'm creating
> mqueues, wrapped to the pthread_rt library.
> I can read and write the mqueue (and it goes through Xenomai), but
> when I select() on a receiving mqd_t, the select() calls returns that
> there is data available on the mq (it fills in the FD_SET), but keeps
> doing so even when it's empty (the select() is in a loop). Also, it's
> modeswitching like nuts.
>
> I found out that the __wrap_select is correctly called, but returns
> -EPERM. Kernel sources indicate that this is caused by
> pse51_current_thread() alias thread2pthread() returning null. Since
> EPERM is returned to userspace, the __real_select is called from user
> space, causing the mode switches and bad behaviour. This is almost
> certainly the thing that native + RTDM + select() is seeing too.
>
> My mqueues-only work probably because mq.c only uses
> pse51_current_thread() in the mq_notify function. I'm guessing that
> mq_notify would also not work in combination with native skin.
>
> I had two options in fixing this: add a xnselector to the native task
> struct or to the nucleus xnthread_t. I choose the latter, such that
> every skin kan use select() + RTDM and migrate gradualy to the RTDM
> and/or Posix skin.
> I needed to free the xnselector structure in xnpod_delete_thread() , I
> chose a spot, but it causes a segfault in my native thread (which did
> the select) during program cleanup. Any advice ? Also, maybe we should
> separate select() from the posix skin and put it in a separate place
> (in RTDM as rtdm_select() ?), such that we can start building around
> it (posix just forwards to rtdm_select() then).
>
> A second patch was necessary to return the timeout case properly to
> userspace (independent of first patch).
>
> Tested with native + posix loaded and mq. If you never quit your
> application, this works :-)
>
> (maybe we discuss this better further on xenomai-core)
Ok. Got it now. My idea with that the nucleus service xnselect could be
used to implement select-like services which would have different
semantics depending on the skins.
So, the select service with posix semantics was reserved to posix skin
threads.
--
Gilles
next prev parent reply other threads:[~2009-10-01 14:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-01 14:30 [Xenomai-core] select: native tasks with posix skin mqueues Peter Soetens
2009-10-01 14:47 ` Gilles Chanteperdrix [this message]
2009-10-01 15:18 ` [Xenomai-core] [Xenomai-help] " Peter Soetens
2009-10-01 15:34 ` Gilles Chanteperdrix
2009-10-02 9:31 ` Peter Soetens
2009-10-02 10:17 ` Gilles Chanteperdrix
2009-10-02 12:51 ` Gilles Chanteperdrix
2009-11-05 1:46 ` [Xenomai-core] " Gilles Chanteperdrix
2009-11-05 20:10 ` Philippe Gerum
2009-11-30 14:20 ` Peter Soetens
2009-11-30 14:26 ` Gilles Chanteperdrix
2009-12-14 10:28 ` Peter Soetens
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=4AC4C11F.2030806@domain.hid \
--to=gilles.chanteperdrix@xenomai.org \
--cc=Xenomai-core@domain.hid \
--cc=peter@domain.hid \
/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.