Who should set the priority of a select(2)ing thread being waken up?
Seigo Tanimura
tanimura at tanimura.dyndns.org
Tue Oct 21 20:21:46 PDT 2003
In good old days, only a socket and a pipe were the major file
descriptors being select(2)ed. As select(2) was just a socket
operation, it was sufficient to set the priority of select(2)ing
process to PSOCK(*1), I suppose.
Nowadays, quite a few drivers support select(2) as well, including
sound, usb, scsi controllers, and so on. I am not convinced whether a
process should select(2) those devices at PSOCK as we do for a socket.
Suppose that a process select(2)s for a pcm device and a socket at
once. If the process is waken up by the pcm driver at PSOCK, another
process at a better priority may preempt the first one, which can
result in dropping some pcm data.
Maybe it would be better if the caller of selwakeup() could determine
the priority of a process or a thread. That would let us raise the
priority to PRIBIO if pcm data was ready, while the priority would
stay at PSOCK if the socket was ready.
(*1) I broke that in 5-CURRENT when I modified select(2) and poll(2)
to use a conditional variable.
--
Seigo Tanimura <tanimura at tanimura.dyndns.org> <tanimura at FreeBSD.org>
More information about the freebsd-arch
mailing list