From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4AA6DE47.8010804@domain.hid> Date: Wed, 09 Sep 2009 00:44:23 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: <793108.19562.qm@domain.hid> <4AA691B8.4090204@domain.hid> <394564.56258.qm@domain.hid> <4AA6D85C.8040707@domain.hid> <982599.63991.qm@domain.hid> In-Reply-To: <982599.63991.qm@domain.hid> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Guvenc Gulce Cc: xenomai@xenomai.org Guvenc Gulce wrote: > Guvenc Gulce wrote: > >>>> Leaving Xenomai domain is not bad per se. The reason why it is bad is >>>> that when re-entering Linux domain, you may have to wait an unbounded >>>> time for Linux to let your task run. >>> Exactly and that would disturb the real-timeliness of the rt task. >>> >>>> With your approach, the first RT task would not leave the Xenomai >>>> domain, but it would wait for the second RT task to complete. And the >>>> second RT task would risk to wait for the same unbounded time. >>> Why should the first RT Task wait for the second RT Task when >>> the second RT Task has lower priority than the first one ? If Xenomai >>> scheduler works as expected then the first rt task should be >>> able to continue to run after writing into Posix Queue (marshalled Linux >>> call) and collect the results of the called linux function when >>> the second rt task gets them and marshalls them back to a second >>> feedback Queue which can be read by the first RT Task when >>> it is appropriate for it. (Feedback Queue needs to be polled by the >>> first RT Task as there is no async communication possibility in >>> Userspace Realtime Environment) > >>> The main advantage here is that the original RT Task never loses his >>> determinism as it might be doing some other jobs other than waiting >>> for the answers from the called linux functions. >>> >>>> So, in short, you gain nothing. >>> I think the gain is that the original rt task stays deterministic and is still able >>> to call the linux functions and can continue to do his job which needs >>> determinism and may poll the feedback Queue some time later and >>> get the results of the called linux function. >>> Such a thing is impossible to do with the current Xenomai API, > >> Yes, you could do that, though, I do not see any real-world application >> where this would make sense. I mean, if you call a function you >> generally want to get the result immediately. What application do you >> have in mind? > > Opps.. I didnt realize that I was replying to you and not to the list.. > > A typical application would be for example to offer a rt task the > possibility of network communication without disturbing its determinism. > If you send a data over the network, you dont necessarily expect > the reply immediately or write to the file system again without > disturbing the determinism. We have rtnet, a deterministic networking stack. For writing to the filesystem, we have rtdk. -- Gilles.