From: Matthias Schneider <ma30002000@yahoo.de>
To: Philippe Gerum <rpm@xenomai.org>,
"xenomai@xenomai.org" <xenomai@xenomai.org>
Subject: Re: [Xenomai] Issue in notifier_callback while threadobj_lock is being held (forge/mercury)
Date: Thu, 1 May 2014 15:28:40 +0100 (BST) [thread overview]
Message-ID: <1398954520.83749.YahooMailNeo@web171601.mail.ir2.yahoo.com> (raw)
In-Reply-To: <53624587.40005@xenomai.org>
----- Original Message -----
> From: Philippe Gerum <rpm@xenomai.org>
> To: Matthias Schneider <ma30002000@yahoo.de>; "xenomai@xenomai.org" <xenomai@xenomai.org>
> Cc:
> Sent: Thursday, May 1, 2014 3:00 PM
> Subject: Re: [Xenomai] Issue in notifier_callback while threadobj_lock is being held (forge/mercury)
>
> On 05/01/2014 02:52 PM, Philippe Gerum wrote:
>> On 05/01/2014 01:49 PM, Matthias Schneider wrote:
>>
>>> On a first glance the commit seems to work find - I am still verifying.
>>> Simplifying the suspend handling, would sending a SIGNOTIFY signal
>>> straight
>>> to the signal handler instead of using pipe read/write operations be an
>>> equivalent, even simpler alternative as demonstrated in the attached
>>> patch?
>>>
>>
>> IIRC, the reason to base the logic on fasync handling was primarily to
>> allow for extending the scheme to multi-processing setups (copperplate
>> provides mechanisms for sharing most of its core objects between
>> processes). Typically, using an AF_UNIX named socket instead of an
>> anonymous pipe would have made possible to notify threads which belong
>> to different processes the same way.
>
> Plus: passing parameters to the notification messages, which we would
> not be able to do using plain signaling. There are a few inter-process
> requests we still need to implement via the notification system. Once
> they are more specifically framed and scoped, we may get back to this
> optimization. Maybe we could use a mixed approach as well.
>
>
> --
> Philippe.
>
Considering it a generic notification mechanism, fasync also allows queueing
multiple notification messages, which are then executed consecutively in
the corresponding thread's "for (;;)" loop.
My suggestion however was based on the assumption that the notifier-framework
was solely used for suspending threads - so I agree on revising it once other
usages of the mechanism are better defined.
prev parent reply other threads:[~2014-05-01 14:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-26 8:58 [Xenomai] Issue in notifier_callback while threadobj_lock is being held (forge/mercury) Matthias Schneider
2014-04-26 10:32 ` Philippe Gerum
2014-04-26 16:13 ` Philippe Gerum
2014-05-01 11:49 ` Matthias Schneider
2014-05-01 12:52 ` Philippe Gerum
2014-05-01 13:00 ` Philippe Gerum
2014-05-01 14:28 ` Matthias Schneider [this message]
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=1398954520.83749.YahooMailNeo@web171601.mail.ir2.yahoo.com \
--to=ma30002000@yahoo.de \
--cc=rpm@xenomai.org \
--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.