Using an xbuf between two processes

Using an xbuf between two processes

[Russell Johnson]

[-- Attachment #1.1: Type: text/plain, Size: 816 bytes --]

Hello,

 

We are intending to split our current application into two separate
processes - one with the non-realtime code and one with the realtime code
(the realtime app will be forked from the non-realtime one). The xbuf
appears to be the natural solution for transferring data between the two
processes. From what I can tell from using it and reading about it on the
wiki, it should work for not only inter-thread communication but also
inter-process communication, correct? I figure one app will create the xbuf
(making it public) and the other app will open the already created xbuf.
Then they can simply read/write back and forth. I just want to clarify that
this is one of the intended purposes of the xbuf architecture and that we
are not architecting ourselves in the wrong direction.

 

Thanks,

Russell


[-- Attachment #1.2: Type: text/html, Size: 2403 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 6759 bytes --]

Re: Using an xbuf between two processes

[Philippe Gerum]

Russell Johnson <russell.johnson@kratosdefense.com> writes:

> [[S/MIME Signed Part:Undecided]]
> Hello,
>
>  
>
> We are intending to split our current application into two separate processes – one with the non-realtime code and one with the realtime code
> (the realtime app will be forked from the non-realtime one). The xbuf appears to be the natural solution for transferring data between the two
> processes. From what I can tell from using it and reading about it on the wiki, it should work for not only inter-thread communication but also
> inter-process communication, correct? I figure one app will create the xbuf (making it public) and the other app will open the already created
> xbuf. Then they can simply read/write back and forth. I just want to clarify that this is one of the intended purposes of the xbuf architecture
> and that we are not architecting ourselves in the wrong direction.
>
>

This is correct, an xbuf is definitely an IPC too - by definition, any
EVL resource which may have public visibility in /dev/evl may be shared
between processes.

You could also use a EVL (public) proxy [1] for sharing a linux 'file'
object between oob and regular threads regardless of the process they
belong to, while keeping real-time guarantees for the former when they
read from, write to such file. To implement IPC, the file can be a
socket, an eventfd, etc.

[1] https://evlproject.org/core/user-api/proxy/

-- 
Philippe.