From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <982599.63991.qm@domain.hid> References: <793108.19562.qm@domain.hid> <4AA691B8.4090204@domain.hid> <394564.56258.qm@domain.hid> <4AA6D85C.8040707@domain.hid> Date: Tue, 8 Sep 2009 15:41:56 -0700 (PDT) From: Guvenc Gulce In-Reply-To: <4AA6D85C.8040707@domain.hid> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: xenomai@xenomai.org 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. Regards, Guvenc