Re: [Xenomai-help] RT Task RPC over a POSIX/Native Queue

[Guvenc Gulce <gulceg@domain.hid>]

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