Date: Wed, 9 Feb 2005 09:49:24 -0500 From: Brian Fundakowski Feldman <green@freebsd.org> To: Dmitry Agaphonov <rzhe@agava.com> Cc: freebsd-hackers@freebsd.org Subject: Re: kqueue & pthread Message-ID: <20050209144924.GB65523@green.homeunix.org> In-Reply-To: <20050209173625.29d50ffd.rzhe@agava.com> References: <20050209173625.29d50ffd.rzhe@agava.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050209144924.GB65523>