[En-Nut-Discussion] RFC: Wait for Multiple Events

[Matthias Ringwald]

Hi Henrik,

thanks for your interest and sorry for not reading your previous post.

The last two conditions are handled by nut/os events right now.

For the first one, to unblock a read call, you would have to post on  
the queue
the thread is waiting for. For a particular device, you might add an  
extra
function to signal that queue. So this is would not touched by the  
proposed solution.

If you find a way to change the read call to wait on your signal  
queue instead of a normal
one, you can send the "config" change signal and are done.

I will think about your actual case, thanks for pointing this one out.
For a general implementation of signals, all i/o would need to use a  
single signal queque
which does not look so convincing.

Regards,
  Matthias

On 28.04.2006, at 02:55, Henrik Maier wrote:

> Hello Matthias,
>
> I would support such an approach (refer to my post "Asynchronous  
> signals - waking up blocked threads" from 28/3) as I also like to  
> wake up a blocked thread with multiple events (and/or signals). I  
> like to use it for example to block a thread until one of the three  
> conditions are true:
>
> 1. data received (read call for example)
> 2. time-out
> 3. Configuration change notification from supervisory thread
>
> Could this be achieved with your method?
>
> Best Regards
>
> Henrik Maier