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