Re: [Xenomai-help] rtdm_event_timedwait non-realtime alternative

["Petr Cervenka" <grugh@domain.hid>]

I sense, that there could be a problem. the rtdm_nrtsig_handler_t handler have only one argument (rtdm_nrtsig_t *). But I need to get a pointer to the device and/or the event which has happended and needs to be forwarded to tha waiter.
I hope there is a possibility to search all my devices (usualy one :-)) if the argument belongs to it, and then clear all pending "events" and call wake_up for appropriate wait queues.
But it's not as simple as I wanted :-(, I hoped that I can avoid the waiting queues etc..
Anyway thanks for help. I didn't know, that I can't use wake_up from RT interrupt handler.
Petr Cervenka
______________________________________________________________
> Od: jan.kiszka@domain.hid
> Komu:  Petr Cervenka <grugh@domain.hid>
> CC:  xenomai@xenomai.org
> Datum: 16.05.2006 13:15
> Předmět: Re: [Xenomai-help] rtdm_event_timedwait non-realtime alternative
>
>  Petr Cervenka wrote:
> > Hello,
> > I need to wait in my ioctl handler for an interrrupt. Is it possible to
> use some rtdm_event_timedwait alternative in non-realtime?
> > I'm thinking about using wait_event_interruptible_timeout. Is it a good
> idea or is there a better solution (e.g. rtdm_event compatible))?
> 
> So your interrupt is RT while one of your waiters is non-RT? Then you
> have to forward the RT event (i.e. the IRQ occurrence) via an
> rtdm_nrtsig_t from the IRQ handler to an nrtsig-event handler in non-RT
> context. This handler can then wakeup non-RT waiters.
> 
> This may sound a bit complicated, but you have to remind that there is
> no safe way to schedule a non-RT (Linux) thread directly from the RT
> (Xenomai) domain, because all Linux scheduling services are fully
> preemptible by Xenomai at any time (including the RT IRQ handler).
> 
> Hmm, as you were asking for a non-RT-safe rtdm_event now: the pattern I
> described above might be generalisable to an extended rtdm_event
> supporting both RT and non-RT waiters (non-RT wakers already work). Need
> to think about this...
> 
> Jan
> 
> 
>