kqueue & pthread

Brian Fundakowski Feldman green at freebsd.org
Wed Feb 9 06:49:26 PST 2005

On Wed, Feb 09, 2005 at 05:36:25PM +0300, Dmitry Agaphonov wrote:
> Hello all,
> There's a server application that use non-bloking sockets with kqueue in
> its main thread and blocking I/O in two auxiliary threads.  While watching
> the server in top(1), I've noticed that it is in the 'poll' state instead
> of 'kqread'.  And breaking the server process execution in the debugger
> drops to __sys_poll() instead of kevent().
> So, the question is: does it really mean that linking to libc_r forces me
> to use poll (somehow internally?) and lose the benefit from using kqueue
> system?
> I'm using gcc-3.4.4 with -pthread option.  FreeBSD version is 4.10-STABLE.
> Thanks.

Since you're using user threads, not kernel threads, the kernel can only
have one "object" (poll or select list, or kqueue file descriptor) to wait
upon at any given time.  Since kqueues are pollable, what happens is
that the kqueue along with every other fd being polled/selected are all
polled by a single poll(2) system call.  Yes, your kqueue is being used,
but it has an indirection of another poll(2) system call determining
when your kevent(2) thread should be woken up.

Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\

More information about the freebsd-hackers mailing list