[Xenomai-help] Intermixing native and POSIX skins

[Xenomai-help] Intermixing native and POSIX skins

[Doug Brunner]

I'd like to be able to use native skin communications services (most importantly real time pipes) from a thread created with the POSIX skin. Is this safe?

I'm doing this because I'm building a C++ library that can use either real-time communications services, when used with a real-time application, or regular Linux pipe I/O, when used with a Linux application; these services are called by tasks that need to exist in both cases. I'd like to make the tasks always POSIX threads to eliminate the need for a bunch of wrappers and preprocessor ugliness that I put there to support either skin, depending on which version of the library is being built.

Thanks,
    Doug Brunner

Re: [Xenomai-help] Intermixing native and POSIX skins

[Philippe Gerum]

On 03/12/2012 08:12 PM, Doug Brunner wrote:
> I'd like to be able to use native skin communications services (most importantly real time pipes) from a thread created with the POSIX skin. Is this safe?

Yes, that's fine. You could also use the XDDP protocol (cross-domain 
datagram) implemented by the RTIPC Xenomai driver for exactly the same 
purpose, with a socket-based interface as a bonus.

>
> I'm doing this because I'm building a C++ library that can use either real-time communications services, when used with a real-time application, or regular Linux pipe I/O, when used with a Linux application; these services are called by tasks that need to exist in both cases. I'd like to make the tasks always POSIX threads to eliminate the need for a bunch of wrappers and preprocessor ugliness that I put there to support either skin, depending on which version of the library is being built.
>
> Thanks,
>      Doug Brunner
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid
> https://mail.gna.org/listinfo/xenomai-help
>


-- 
Philippe.

Re: [Xenomai-help] Intermixing native and POSIX skins

[Doug Brunner]

Thanks Philippe. I hadn't even known about the existence of the RTIPC driver, and I definitely like the idea.

I've been experimenting with it a bit today, and found that it seems to be allowed for more than two sockets to connect to the same port. I modified iddp-sendrecv.c to have two client processes, both of which now connect to the same port as the server, then did the same thing with iddp-label.c (two clients both connect()ing to the same label).

This would cause havoc with the communications that go on between my processes--they need a one-to-one channel. I could implement semaphores to enforce this, but it would be nice to avoid that complication. Is there a way to make it happen using just the socket interface?

    Doug Brunner

-----Original Message-----
From: "Philippe Gerum" <rpm@xenomai.orgnomai.org>
Sent: Monday, March 12, 2012 12:43pm
To: "Doug Brunner" <dbrunner@domain.hid>
Cc: xenomai@xenomai.org: Re: [Xenomai-help] Intermixing native and POSIX skins

On 03/12/2012 08:12 PM, Doug Brunner wrote:
> I'd like to be able to use native skin communications services (most importantly real time pipes) from a thread created with the POSIX skin. Is this safe?

Yes, that's fine. You could also use the XDDP protocol (cross-domain 
datagram) implemented by the RTIPC Xenomai driver for exactly the same 
purpose, with a socket-based interface as a bonus.

>
> I'm doing this because I'm building a C++ library that can use either real-time communications services, when used with a real-time application, or regular Linux pipe I/O, when used with a Linux application; these services are called by tasks that need to exist in both cases. I'd like to make the tasks always POSIX threads to eliminate the need for a bunch of wrappers and preprocessor ugliness that I put there to support either skin, depending on which version of the library is being built.
>
> Thanks,
>      Doug Brunner
>
>
>
> _______________________________________________
> Xenomai-help mailing list
> Xenomai-help@domain.hid> https://mail.gna.org/listinfo/xenomai-help
>


-- 
Philippe.

Re: [Xenomai-help] Intermixing native and POSIX skins

[Philippe Gerum]

On 03/15/2012 05:30 PM, Doug Brunner wrote:
> Thanks Philippe. I hadn't even known about the existence of the RTIPC driver, and I definitely like the idea.
>
> I've been experimenting with it a bit today, and found that it seems to be allowed for more than two sockets to connect to the same port. I modified iddp-sendrecv.c to have two client processes, both of which now connect to the same port as the server, then did the same thing with iddp-label.c (two clients both connect()ing to the same label).
>
> This would cause havoc with the communications that go on between my processes--they need a one-to-one channel. I could implement semaphores to enforce this, but it would be nice to avoid that complication. Is there a way to make it happen using just the socket interface?

The RTIPC protocols are fundamentally datagram-based, so allowing N:1 
data paths is wanted. If the issue is about picking a different port 
each time you bind a server socket in the AF_RTIPC domain, then I would 
suggest to set sipc_port to -1 when binding the server-side socket: a 
free port will be picked automatically. You could then use getsockname() 
to retrieve the actual port #, and pass it to the clients.

>
>      Doug Brunner
>
> -----Original Message-----
> From: "Philippe Gerum"<rpm@xenomai.org>
> Sent: Monday, March 12, 2012 12:43pm
> To: "Doug Brunner"<dbrunner@domain.hid>
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] Intermixing native and POSIX skins
>
> On 03/12/2012 08:12 PM, Doug Brunner wrote:
>> I'd like to be able to use native skin communications services (most importantly real time pipes) from a thread created with the POSIX skin. Is this safe?
>
> Yes, that's fine. You could also use the XDDP protocol (cross-domain
> datagram) implemented by the RTIPC Xenomai driver for exactly the same
> purpose, with a socket-based interface as a bonus.
>
>>
>> I'm doing this because I'm building a C++ library that can use either real-time communications services, when used with a real-time application, or regular Linux pipe I/O, when used with a Linux application; these services are called by tasks that need to exist in both cases. I'd like to make the tasks always POSIX threads to eliminate the need for a bunch of wrappers and preprocessor ugliness that I put there to support either skin, depending on which version of the library is being built.
>>
>> Thanks,
>>       Doug Brunner
>>
>>
>>
>> _______________________________________________
>> Xenomai-help mailing list
>> Xenomai-help@domain.hid
>> https://mail.gna.org/listinfo/xenomai-help
>>
>
>


-- 
Philippe.

Re: [Xenomai-help] Intermixing native and POSIX skins

[Doug Brunner]

Thanks for the information--the issue is not about picking a free port on the server side, but rather about communicating the information on which ports are "free" to the clients (server has connected its end, but no other client is using the port). The semaphore mechanism isn't that much of a problem, though; I've been able to build a satisfactory implementation.

One other question: although I know in-order delivery isn't necessarily a feature of datagram based protocols, would I get that with an IDDP socket connection between just two processes, and/or an XDDP connection to a /dev/rtpN?

    Doug Brunner

-----Original Message-----
From: "Philippe Gerum" <rpm@xenomai.org>
Sent: Friday, March 16, 2012 11:29am
To: "Doug Brunner" <dbrunner@domain.hid>
Cc: xenomai@xenomai.org: Re: [Xenomai-help] Intermixing native and POSIX skins

On 03/15/2012 05:30 PM, Doug Brunner wrote:
> Thanks Philippe. I hadn't even known about the existence of the RTIPC driver, and I definitely like the idea.
>
> I've been experimenting with it a bit today, and found that it seems to be allowed for more than two sockets to connect to the same port. I modified iddp-sendrecv.c to have two client processes, both of which now connect to the same port as the server, then did the same thing with iddp-label.c (two clients both connect()ing to the same label).
>
> This would cause havoc with the communications that go on between my processes--they need a one-to-one channel. I could implement semaphores to enforce this, but it would be nice to avoid that complication. Is there a way to make it happen using just the socket interface?

The RTIPC protocols are fundamentally datagram-based, so allowing N:1 
data paths is wanted. If the issue is about picking a different port 
each time you bind a server socket in the AF_RTIPC domain, then I would 
suggest to set sipc_port to -1 when binding the server-side socket: a 
free port will be picked automatically. You could then use getsockname() 
to retrieve the actual port #, and pass it to the clients.

-- 
Philippe.

Re: [Xenomai-help] Intermixing native and POSIX skins

[Philippe Gerum]

On 03/26/2012 06:14 PM, Doug Brunner wrote:
> Thanks for the information--the issue is not about picking a free port on the server side, but rather about communicating the information on which ports are "free" to the clients (server has connected its end, but no other client is using the port). The semaphore mechanism isn't that much of a problem, though; I've been able to build a satisfactory implementation.

Mm, still scratching my head to understand the issue. Both the client 
and server side accept -1 as the port spec, telling the kernel to draw a 
free port. I understand the issue is not on the server side, so is it on 
the client side?

Could you sketch the usage pattern?

>
> One other question: although I know in-order delivery isn't necessarily a feature of datagram based protocols, would I get that with an IDDP socket connection between just two processes, and/or an XDDP connection to a /dev/rtpN?

Yes, in-order delivery is guaranteed with all RTIPC protocols. This is 
written in stone.

>
>      Doug Brunner
>
> -----Original Message-----
> From: "Philippe Gerum"<rpm@xenomai.org>
> Sent: Friday, March 16, 2012 11:29am
> To: "Doug Brunner"<dbrunner@domain.hid>
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] Intermixing native and POSIX skins
>
> On 03/15/2012 05:30 PM, Doug Brunner wrote:
>> Thanks Philippe. I hadn't even known about the existence of the RTIPC driver, and I definitely like the idea.
>>
>> I've been experimenting with it a bit today, and found that it seems to be allowed for more than two sockets to connect to the same port. I modified iddp-sendrecv.c to have two client processes, both of which now connect to the same port as the server, then did the same thing with iddp-label.c (two clients both connect()ing to the same label).
>>
>> This would cause havoc with the communications that go on between my processes--they need a one-to-one channel. I could implement semaphores to enforce this, but it would be nice to avoid that complication. Is there a way to make it happen using just the socket interface?
>
> The RTIPC protocols are fundamentally datagram-based, so allowing N:1
> data paths is wanted. If the issue is about picking a different port
> each time you bind a server socket in the AF_RTIPC domain, then I would
> suggest to set sipc_port to -1 when binding the server-side socket: a
> free port will be picked automatically. You could then use getsockname()
> to retrieve the actual port #, and pass it to the clients.
>


-- 
Philippe.

Re: [Xenomai-help] Intermixing native and POSIX skins

[Doug Brunner]

The usage pattern would be a bit like BSD ptys--the server maintains a few ports, say named "server0" through "server15" and clients that need a port try "server0", if it's busy then try "server1", etc..

I suppose the problem here is really that the application running over these sockets is stateful, the configuration of the nodes (processes) that are communicating is not known until run time, and nodes may appear and disappear as the server runs, so the transport needs to be connection-oriented rather than message-oriented. The semaphore is still a bit of a kludge, since it doesn't notify a thread blocked on recv() that the remote has hung up, but it works well enough in conjunction with a message that says "I'm a client that's newly connected to this server" to reset the state associated with the connection. I suppose I could implement a sort of TCP handshake on top of the IDDP socket layer and use that to provide true connection-oriented behavior.

Good to know about in-order delivery; a quick glance at the source code seemed to suggest that, but I wasn't sure.

    Doug Brunner

-----Original Message-----
From: "Philippe Gerum" <rpm@xenomai.org>
Sent: Tuesday, March 27, 2012 9:26am
To: "Doug Brunner" <dbrunner@domain.hid>
Cc: xenomai-help@domain.hid: Re: [Xenomai-help] Intermixing native and POSIX skins

On 03/26/2012 06:14 PM, Doug Brunner wrote:
> Thanks for the information--the issue is not about picking a free port on the server side, but rather about communicating the information on which ports are "free" to the clients (server has connected its end, but no other client is using the port). The semaphore mechanism isn't that much of a problem, though; I've been able to build a satisfactory implementation.

Mm, still scratching my head to understand the issue. Both the client 
and server side accept -1 as the port spec, telling the kernel to draw a 
free port. I understand the issue is not on the server side, so is it on 
the client side?

Could you sketch the usage pattern?

>
> One other question: although I know in-order delivery isn't necessarily a feature of datagram based protocols, would I get that with an IDDP socket connection between just two processes, and/or an XDDP connection to a /dev/rtpN?

Yes, in-order delivery is guaranteed with all RTIPC protocols. This is 
written in stone.

>
>      Doug Brunner
>
> -----Original Message-----
> From: "Philippe Gerum"<rpm@xenomai.org>
> Sent: Friday, March 16, 2012 11:29am
> To: "Doug Brunner"<dbrunner@domain.hid>
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] Intermixing native and POSIX skins
>
> On 03/15/2012 05:30 PM, Doug Brunner wrote:
>> Thanks Philippe. I hadn't even known about the existence of the RTIPC driver, and I definitely like the idea.
>>
>> I've been experimenting with it a bit today, and found that it seems to be allowed for more than two sockets to connect to the same port. I modified iddp-sendrecv.c to have two client processes, both of which now connect to the same port as the server, then did the same thing with iddp-label.c (two clients both connect()ing to the same label).
>>
>> This would cause havoc with the communications that go on between my processes--they need a one-to-one channel. I could implement semaphores to enforce this, but it would be nice to avoid that complication. Is there a way to make it happen using just the socket interface?
>
> The RTIPC protocols are fundamentally datagram-based, so allowing N:1
> data paths is wanted. If the issue is about picking a different port
> each time you bind a server socket in the AF_RTIPC domain, then I would
> suggest to set sipc_port to -1 when binding the server-side socket: a
> free port will be picked automatically. You could then use getsockname()
> to retrieve the actual port #, and pass it to the clients.
>


-- 
Philippe.

[Xenomai-core] [PATCH] Mask signals in rt_print:printer_loop()

[Paul Janzen]

common/rt_print: Use sigfillset to actually mask all signals for
logging thread.  Fixes commit a6dceeb9.

Signed-off-by: Paul Janzen <pcj@domain.hid>
---
 src/skins/common/rt_print.c |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/src/skins/common/rt_print.c b/src/skins/common/rt_print.c
index e1c828a..272a4ba 100644
--- a/src/skins/common/rt_print.c
+++ b/src/skins/common/rt_print.c
@@ -615,7 +615,7 @@ static void *printer_loop(void *arg)
 {
        sigset_t mask;
 
-       sigemptyset(&mask);
+       sigfillset(&mask);
        pthread_sigmask(SIG_BLOCK, &mask, NULL);
 
        while (1) {
-- 
1.7.1

Re: [Xenomai-core] [PATCH] Mask signals in rt_print:printer_loop()

[Gilles Chanteperdrix]

On 03/28/2012 07:39 AM, Paul Janzen wrote:
> common/rt_print: Use sigfillset to actually mask all signals for
> logging thread.  Fixes commit a6dceeb9.

Thanks, but patch fails to apply on xenomai 2.6 master branch.

-- 
					    Gilles.

Re: [Xenomai-help] Intermixing native and POSIX skins

[Philippe Gerum]

On 03/27/2012 11:35 PM, Doug Brunner wrote:
> The usage pattern would be a bit like BSD ptys--the server maintains a few ports, say named "server0" through "server15" and clients that need a port try "server0", if it's busy then try "server1", etc..

An option to mimic this partially might be to define a fixed port number 
clients would use to ask the server for a free port to connect to later 
on? The server would let the RTIPC layer pick a free port when binding, 
then return it to the client via a converse message to the fixed port.

>
> I suppose the problem here is really that the application running over these sockets is stateful, the configuration of the nodes (processes) that are communicating is not known until run time, and nodes may appear and disappear as the server runs, so the transport needs to be connection-oriented rather than message-oriented. The semaphore is still a bit of a kludge, since it doesn't notify a thread blocked on recv() that the remote has hung up, but it works well enough in conjunction with a message that says "I'm a client that's newly connected to this server" to reset the state associated with the connection. I suppose I could implement a sort of TCP handshake on top of the IDDP socket layer and use that to provide true connection-oriented behavior.

Yep, RTIPC won't help that much by default in that area, it only 
exhibits connectionless semantics.

>
> Good to know about in-order delivery; a quick glance at the source code seemed to suggest that, but I wasn't sure.
>
>      Doug Brunner
>
> -----Original Message-----
> From: "Philippe Gerum"<rpm@xenomai.org>
> Sent: Tuesday, March 27, 2012 9:26am
> To: "Doug Brunner"<dbrunner@domain.hid>
> Cc: xenomai@xenomai.org
> Subject: Re: [Xenomai-help] Intermixing native and POSIX skins
>
> On 03/26/2012 06:14 PM, Doug Brunner wrote:
>> Thanks for the information--the issue is not about picking a free port on the server side, but rather about communicating the information on which ports are "free" to the clients (server has connected its end, but no other client is using the port). The semaphore mechanism isn't that much of a problem, though; I've been able to build a satisfactory implementation.
>
> Mm, still scratching my head to understand the issue. Both the client
> and server side accept -1 as the port spec, telling the kernel to draw a
> free port. I understand the issue is not on the server side, so is it on
> the client side?
>
> Could you sketch the usage pattern?
>
>>
>> One other question: although I know in-order delivery isn't necessarily a feature of datagram based protocols, would I get that with an IDDP socket connection between just two processes, and/or an XDDP connection to a /dev/rtpN?
>
> Yes, in-order delivery is guaranteed with all RTIPC protocols. This is
> written in stone.
>
>>
>>       Doug Brunner
>>
>> -----Original Message-----
>> From: "Philippe Gerum"<rpm@xenomai.org>
>> Sent: Friday, March 16, 2012 11:29am
>> To: "Doug Brunner"<dbrunner@domain.hid>
>> Cc: xenomai@xenomai.org
>> Subject: Re: [Xenomai-help] Intermixing native and POSIX skins
>>
>> On 03/15/2012 05:30 PM, Doug Brunner wrote:
>>> Thanks Philippe. I hadn't even known about the existence of the RTIPC driver, and I definitely like the idea.
>>>
>>> I've been experimenting with it a bit today, and found that it seems to be allowed for more than two sockets to connect to the same port. I modified iddp-sendrecv.c to have two client processes, both of which now connect to the same port as the server, then did the same thing with iddp-label.c (two clients both connect()ing to the same label).
>>>
>>> This would cause havoc with the communications that go on between my processes--they need a one-to-one channel. I could implement semaphores to enforce this, but it would be nice to avoid that complication. Is there a way to make it happen using just the socket interface?
>>
>> The RTIPC protocols are fundamentally datagram-based, so allowing N:1
>> data paths is wanted. If the issue is about picking a different port
>> each time you bind a server socket in the AF_RTIPC domain, then I would
>> suggest to set sipc_port to -1 when binding the server-side socket: a
>> free port will be picked automatically. You could then use getsockname()
>> to retrieve the actual port #, and pass it to the clients.
>>
>
>


-- 
Philippe.