Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side
Hi Gilles, On 03/23/2012 02:14 PM, Gilles Chanteperdrix wrote: On 03/23/2012 10:59 AM, Gilles Chanteperdrix wrote: On 03/23/2012 09:35 AM, Wolfgang Grandegger wrote: Hello, while playing with rt_pipe, I realized that a select()/poll() function does not unblock when the rt_pipe is deleted (via rt_pipe_delete) on the other end. I think this is because the poll callback does not support POLLHUP: http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#1024 Is this by purpose? At least a blocking read() works as expected. It does unblock and return 0 in that case. rt_pipes are deprecated, we are not going to add new features to them now. Please do not use them for new developments. We now have socket based RTIPCs. See examples/rtdm/profiles/ipc. Ah, I was not aware of that. This solution does also work for any skin (and does not require to misuse the native skin any more). On the other hand, if you have a small patch to fix this, I will not hurt anyone to merge it. OK. See patch below. Wolfgang. From 49eeb2b8451a68d10a7f1768e2bf74dcdaf3e35e Mon Sep 17 00:00:00 2001 From: Wolfgang Grandegger w...@denx.de Date: Mon, 26 Mar 2012 09:21:51 +0200 Subject: [PATCH] nucleus: fix poll EOF issue with xnpipe/rt_pipe So far, the EOF event is not handled in the Linux poll function of the xnpipe/rt_pipe service when the pipe is closed (via rt_pipde_delete). This patch fixes the issue by setting POLLUP in the Linux poll function when the pipe is broken. The subsequent reads will then fail with errno EPIPE. Signed-off-by: Wolfgang Grandegger w...@denx.de --- ksrc/nucleus/pipe.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/ksrc/nucleus/pipe.c b/ksrc/nucleus/pipe.c index 1e6bcf2..1d5e39a 100644 --- a/ksrc/nucleus/pipe.c +++ b/ksrc/nucleus/pipe.c @@ -1033,6 +1033,8 @@ static unsigned xnpipe_poll(struct file *file, poll_table *pt) if (testbits(state-status, XNPIPE_KERN_CONN)) w_mask |= (POLLOUT | POLLWRNORM); + else + r_mask |= POLLHUP; if (!emptyq_p(state-outq)) r_mask |= (POLLIN | POLLRDNORM); -- 1.7.7.6 ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side
On 03/26/2012 11:38 AM, Wolfgang Grandegger wrote: Hi Gilles, On 03/23/2012 02:14 PM, Gilles Chanteperdrix wrote: On 03/23/2012 10:59 AM, Gilles Chanteperdrix wrote: On 03/23/2012 09:35 AM, Wolfgang Grandegger wrote: Hello, while playing with rt_pipe, I realized that a select()/poll() function does not unblock when the rt_pipe is deleted (via rt_pipe_delete) on the other end. I think this is because the poll callback does not support POLLHUP: http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#1024 Is this by purpose? At least a blocking read() works as expected. It does unblock and return 0 in that case. rt_pipes are deprecated, we are not going to add new features to them now. Please do not use them for new developments. We now have socket based RTIPCs. See examples/rtdm/profiles/ipc. Ah, I was not aware of that. This solution does also work for any skin (and does not require to misuse the native skin any more). BTW, is there another interface (whith less overhead) to signal Linux thread from RT threads to trigger some work, e.g. for reading from shmem? Wolfgang. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side
On 03/26/2012 11:48 AM, Wolfgang Grandegger wrote: On 03/26/2012 11:38 AM, Wolfgang Grandegger wrote: Hi Gilles, On 03/23/2012 02:14 PM, Gilles Chanteperdrix wrote: On 03/23/2012 10:59 AM, Gilles Chanteperdrix wrote: On 03/23/2012 09:35 AM, Wolfgang Grandegger wrote: Hello, while playing with rt_pipe, I realized that a select()/poll() function does not unblock when the rt_pipe is deleted (via rt_pipe_delete) on the other end. I think this is because the poll callback does not support POLLHUP: http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#1024 Is this by purpose? At least a blocking read() works as expected. It does unblock and return 0 in that case. rt_pipes are deprecated, we are not going to add new features to them now. Please do not use them for new developments. We now have socket based RTIPCs. See examples/rtdm/profiles/ipc. Ah, I was not aware of that. This solution does also work for any skin (and does not require to misuse the native skin any more). BTW, is there another interface (whith less overhead) to signal Linux thread from RT threads to trigger some work, e.g. for reading from shmem? The simplest thing to do in such a case is to make the Linux thread a Xenomai thread but running with the SCHED_OTHER policy, you can then use simpler IPCs such as semaphores. Starting with Xenomai 2.6.0, such a thread is guaranteed to return to secondary mode as soon as possible. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side
On 03/26/2012 11:53 AM, Gilles Chanteperdrix wrote: On 03/26/2012 11:48 AM, Wolfgang Grandegger wrote: On 03/26/2012 11:38 AM, Wolfgang Grandegger wrote: Hi Gilles, On 03/23/2012 02:14 PM, Gilles Chanteperdrix wrote: On 03/23/2012 10:59 AM, Gilles Chanteperdrix wrote: On 03/23/2012 09:35 AM, Wolfgang Grandegger wrote: Hello, while playing with rt_pipe, I realized that a select()/poll() function does not unblock when the rt_pipe is deleted (via rt_pipe_delete) on the other end. I think this is because the poll callback does not support POLLHUP: http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#1024 Is this by purpose? At least a blocking read() works as expected. It does unblock and return 0 in that case. rt_pipes are deprecated, we are not going to add new features to them now. Please do not use them for new developments. We now have socket based RTIPCs. See examples/rtdm/profiles/ipc. Ah, I was not aware of that. This solution does also work for any skin (and does not require to misuse the native skin any more). At a closer look to the RTIPC interfaces I realized, that they are also based on xnpipe, like rt_pipe. Therefore a patch for the EOF issue is also here required. BTW, is there another interface (whith less overhead) to signal Linux thread from RT threads to trigger some work, e.g. for reading from shmem? The simplest thing to do in such a case is to make the Linux thread a Xenomai thread but running with the SCHED_OTHER policy, you can then use simpler IPCs such as semaphores. Starting with Xenomai 2.6.0, such a thread is guaranteed to return to secondary mode as soon as possible. OK. Wolfgang. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] Intermixing native and POSIX skins
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 r...@xenomai.org Sent: Friday, March 16, 2012 11:29am To: Doug Brunner dbrun...@ebus.com Cc: xenomai-help@gna.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-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
[Xenomai-help] error with rt_pipe
Hi I have these errors when I'm trying to make an example of pipe cc -I/usr/include/xenomai -D_GNU_SOURCE -D_REENTRANT -Wall -Werror-implicit-function-declaration -pipe -D__XENO__ test_pipe.c -lnative -L/usr/lib -lxenomai -lpthread -lrt -lrtdm -lpthread -Xlinker -rpath /usr/lib -o test_pipe test_pipe.c: In function ‚'task_body‚': test_pipe.c:33: error: 'RT_PIPE_MSG' undeclared (first use in this function) test_pipe.c:33: error: (Each undeclared identifier is reported only once test_pipe.c:33: error: for each function it appears in.) test_pipe.c:33: error: 'msgout' undeclared (first use in this function) test_pipe.c:33: error: 'msgin' undeclared (first use in this function) test_pipe.c:33: warning: left-hand operand of comma expression has no effect test_pipe.c:42: error: implicit declaration of function 'rt_pipe_alloc' test_pipe.c:44: error: implicit declaration of function ‚'fail' test_pipe.c:46: error: implicit declaration of function 'RT_PIPE_MSGPTR' test_pipe.c:47: error: implicit declaration of function 'rt_pipe_send' test_pipe.c:50: error: implicit declaration of function 'rt_pipe_receive' test_pipe.c:52: error: 'n' undeclared (first use in this function) test_pipe.c:53: error: continue statement not within a loop test_pipe.c:58: error: continue statement not within a loop test_pipe.c:62: error: implicit declaration of function 'P_MSGPTR' test_pipe.c:62: error: implicit declaration of function 'P_MSGSIZE' test_pipe.c:64: error: implicit declaration of function 'rt_pipe_free' thanks Daniele ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] error with rt_pipe
On 03/26/2012 08:11 PM, Daniele wrote: Hi I have these errors when I'm trying to make an example of pipe rt_pipes are deprecated, see xddp sockets examples in examples/rtdm/profiles/ipc/xddp* -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side
On 03/26/2012 11:38 AM, Wolfgang Grandegger wrote: Hi Gilles, On 03/23/2012 02:14 PM, Gilles Chanteperdrix wrote: On 03/23/2012 10:59 AM, Gilles Chanteperdrix wrote: On 03/23/2012 09:35 AM, Wolfgang Grandegger wrote: Hello, while playing with rt_pipe, I realized that a select()/poll() function does not unblock when the rt_pipe is deleted (via rt_pipe_delete) on the other end. I think this is because the poll callback does not support POLLHUP: http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/pipe.c#1024 Is this by purpose? At least a blocking read() works as expected. It does unblock and return 0 in that case. rt_pipes are deprecated, we are not going to add new features to them now. Please do not use them for new developments. We now have socket based RTIPCs. See examples/rtdm/profiles/ipc. Ah, I was not aware of that. This solution does also work for any skin (and does not require to misuse the native skin any more). On the other hand, if you have a small patch to fix this, I will not hurt anyone to merge it. OK. See patch below. Merged, thanks. -- Gilles. ___ Xenomai-help mailing list Xenomai-help@gna.org https://mail.gna.org/listinfo/xenomai-help
