[lkml]   [2003]   [Dec]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC,PATCH] use rcu for fasync_lock
On Sun, 21 Dec 2003, Manfred Spraul wrote:

> >What about killing fasync_helper altogether and using the method that
> >epoll uses to register "listeners" which send a signal when the poll
> >state of a device changes?
> >
> I think it would be a step in the wrong direction: poll should go away
> from a simple wake-up to an interface that transfers the band info
> (POLL_IN, POLL_OUT, etc). Right now at least two passes over the f_poll
> functions are necessary, because the info which event actually triggered
> is lost. kill_fasync transfers the band info, thus I don't want to
> remove it.

It is my plan to propose (Linus is not contrary, in principle) a change of
the poll/wake infrastructure for 2.7. There are two areas that can be
improved. First, f_op->poll() does not allow you to send and event mask,
and this requires the driver to indiscriminately wake up both IN and OUT
waiters. The second area will be to give the driver to specify some "info"
for the wake up. Something like:

wake_up_info(&wq, XXXX);

And add to the wait queue item storage for the passed info. Where "info"
could be anything from an event mask, up to an allocated object with its
own destructor. In this way the callback'd waked up will have the "info"
ready w/out issuing an extra f_op->poll(). The code is pretty much
trivial, even if changes will touch a bunch of code. The good thing is
that migration can be gradual, beside the initial dumb compile fixing to
suite the new f_op->poll() interface.

- Davide

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:59    [W:0.170 / U:0.124 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site