From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4F7042EC.5040109@domain.hid> Date: Mon, 26 Mar 2012 12:20:28 +0200 From: Wolfgang Grandegger MIME-Version: 1.0 References: <4F6C35CA.8010506@domain.hid> <4F6C4978.6060108@domain.hid> <4F6C7722.2080609@domain.hid> <4F7038FF.3050203@domain.hid> <4F703B8A.7060307@domain.hid> <4F703CB6.7050907@domain.hid> In-Reply-To: <4F703CB6.7050907@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] rt_pipe does not support POLLHUP on the Linux side List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: xenomai-help 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.