Who should set the priority of a select(2)ing thread being waken up?

[Seigo Tanimura]

[posted to -current as well, because there were no replies in -arch]

On Wed, 22 Oct 2003 19:21:46 +0900,
  Seigo Tanimura <tanimura at tanimura.dyndns.org> said:

tanimura> In good old days, only a socket and a pipe were the major file
tanimura> descriptors being select(2)ed.  As select(2) was just a socket
tanimura> operation, it was sufficient to set the priority of select(2)ing
tanimura> process to PSOCK(*1), I suppose.

tanimura> Nowadays, quite a few drivers support select(2) as well, including
tanimura> sound, usb, scsi controllers, and so on.  I am not convinced whether a
tanimura> process should select(2) those devices at PSOCK as we do for a socket.

tanimura> Suppose that a process select(2)s for a pcm device and a socket at
tanimura> once.  If the process is waken up by the pcm driver at PSOCK, another
tanimura> process at a better priority may preempt the first one, which can
tanimura> result in dropping some pcm data.

tanimura> Maybe it would be better if the caller of selwakeup() could determine
tanimura> the priority of a process or a thread.  That would let us raise the
tanimura> priority to PRIBIO if pcm data was ready, while the priority would
tanimura> stay at PSOCK if the socket was ready.


tanimura> (*1) I broke that in 5-CURRENT when I modified select(2) and poll(2)
tanimura> to use a conditional variable.

tanimura> The attached patch implements selwakeuppri(), which lets you set the
tanimura> priority of a thread being waken up.  Also in the patch is a small
tanimura> test code to use selwakeuppri() in pcm(4).
(patch snipped)

The updated patch at:

http://people.freebsd.org/~tanimura/selwakeuppri.diff.gz

converts all selwakeup()s into selwakeuppri()s with appropriate
priorities.  Old selwakeup() is left, but I may axe it.

Any objections if I commit the patch in a week?

-- 
Seigo Tanimura <tanimura at tanimura.dyndns.org> <tanimura at FreeBSD.org>