Hello,
On Sat, 4 Mar 2000 kuznet@ms2.inr.ac.ru wrote:
> > I think, nobody uses si_band. si_code is enough (POLL_xxx).
>
> Grrr... What a crap, to be honest. Are these fields described
> in any standard? si_code is evident redundancy. Moreover, it
> is not only redundancy, it is deoptimization not allowing to
> merge events, when they can be merged by oring event masks.
It could be very good if these events are merged but currently we
don't know if an event is still unread from the rt queue and not to repeat
it. Because it can be very useful if there is a known maximum of unread
events per fd in the rt queue. By this way we can choose appropriate value
for rtsig-max to avoid rt queue overflow followed by SIGIO and poll() to
detect the fd state. And the number of the events will be minimal.
May be if we remember the event mask per each fd/file and to clear
it when the event is dequeued. But the program must use si_band and not
si_code. The current fd/file event mask can be received in si_band, i.e.
when it is currently and automatically cleared from sig*waitinfo(). By
this way rt queue can contain one entry per file. struct file must
remember the position of its event mask in the rt queue. If the event is
dequeued the event mask is assumed 0 because the file->pointer_to_rt_queue
will be 0. When the event mask is created in the rt queue we have to
send the signal, i.e. only once. If more events arrive we just put them in
the mask. May be it is possible this to be implemented. But I don't know
if event merging is useful for all drivers. For sockets - yes. May be this
feature can be optional?
Regards
-- Julian Anastasov <uli@linux.tu-varna.acad.bg>- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Mar 07 2000 - 21:00:18 EST