Michel Oosterhof wrote:
> I've got one more question, actually a fact that surprises me, it
> seems that tail(1) is the only place in the base system that actually
> uses kqueue. Is there a reason for this? I read in most places
> kqueue() is more efficient, scalable, etc. I'm sure code like ftpd
> or other services would benefit. (And i'm sure Apache could use it
> too).
I've got local patches here that convert the RPC library to
use kqueue instead of select.
The obvious objection to such changes is that the internals
of the RPC library are sufficiently exposed that there is a
near-dependency on the use of select; if you look at the "rpc"
man page, for example, you will see, among other things:
fd_set svc_fdset;
A global variable reflecting the RPC service side's read file
descriptor bit mask; it is suitable as a template parameter to
the select(2) system call. This is only of interest if a service
implementor does not call svc_run(), but rather does his own
asynchronous event processing. This variable is read-only (do
not pass its address to select(2)!), yet it may change after
calls to svc_getreqset() or any creation routines. As well, note
that if the process has descriptor limits which are extended
beyond FD_SETSIZE, this variable will only be usable for the
first FD_SETSIZE descriptors.
Moving to kqueue overcomes this limitation (the actual limitation,
if you read the code in depth, is "32", which is much worse than
the man page implies). But it also means that programs that have
been written to take advantage of these somewhat arcane and mostly
(in the programming guides) undocumented hooks would no longer
function, without themselves needing to be rewritten to use kqueue.
It's good enough for me to use locally, to permit control and
configuration (e.g. it's very easy to wire SNMP into existing
programs, if they are based on kqueue, and you have an RPC
library that's also based on kqueue), but the loss of the ability
to use other RPC-aware code without rewriting it is mayb too much
for the changes to be generally acceptable to everyone.
It doesn't help that you change one undocumented arcane interface
for replacing the main select loop, with another undocumented,
arcane interface for replacing the kqueue (not *as* arcane; a
kqueue can be registered in a kqueue for events, so that when an
event occurs on the second, you get an event on the first that
allows you to dispatch to a work routine on the second).
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
