Re: Waiting for 'high priority' events with kqueue

[christos%astron.com@localhost (Christos Zoulas)]

In article <CAEnbY+cD28Rgjiw69_0jxFfFHQtLvwTVOfMRE-Cc8ykBMsNOiQ%mail.gmail.com@localhost>,
Daurnimator  <quae%daurnimator.com@localhost> wrote:
>(sorry, I'm not subbed to list; only saw your reply by looking up archives)
>
>> The only "high priority events" are socket out of band data.
>> EV_OOB is only used in 3 c files:
>>
>> http://fxr.watson.org/fxr/ident?v=xnu-2050.18.24&i=EV_OOB
>>
>> It is simple enough for us to do the same if that's useful.
>>
>> christos
>
>That would be wonderful :)
>
>Though an alternate solution came up over on the OpenBSD list:
>DragonBSD implements EVFILT_EXCEPT in addition to EVFILT_READ and EVFILE_WRITE.
>This seems to be a much cleaner solution, where each of the three map
>cleanly to a select() set.
>(OSX has a few weird bugs when there are both POLLIN AND POLLPRI events).
>
>Please let me know if there's anything I can help with.

I will look into that and summarize how I think we should proceed.
Having said all that: Depending on socket OOB messages to provide
functionality is a questionable practice due to the lack of
portability (and hackiness/bugs in the implementations [*]). You are
better off avoiding it.

christos

[*] leaks of OOB data in the regular data stream/resource exhaustion etc.