[Xenomai-help] rt_pipe does not support POLLHUP on the Linux side

[Xenomai-help] rt_pipe does not support POLLHUP on the Linux side

[Wolfgang Grandegger]

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.

Wolfgang.

Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side

[Gilles Chanteperdrix]

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.

-- 
					    Gilles.

Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side

[Gilles Chanteperdrix]

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.
> 

On the other hand, if you have a small patch to fix this, I will not
hurt anyone to merge it.

-- 
					    Gilles.

Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side

[Wolfgang Grandegger]

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 <wg@domain.hid>
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 <wg@domain.hid>
---
 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

Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side

[Wolfgang Grandegger]

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.

Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side

[Gilles Chanteperdrix]

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.

Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side

[Wolfgang Grandegger]

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.

Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side

[Gilles Chanteperdrix]

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.