From owner-freebsd-hackers@FreeBSD.ORG Tue Apr 22 10:59:54 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C3EB37B401 for ; Tue, 22 Apr 2003 10:59:54 -0700 (PDT) Received: from smtp.netli.com (ip2-pal-focal.netli.com [66.243.52.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC49543F85 for ; Tue, 22 Apr 2003 10:59:52 -0700 (PDT) (envelope-from vlm@netli.com) Received: (qmail 17089 invoked by uid 84); 22 Apr 2003 17:59:50 -0000 Received: from vlm@netli.com by l3-1 with qmail-scanner-0.96 (uvscan: v4.1.40/v4121. . Clean. Processed in 0.128998 secs); 22 Apr 2003 17:59:50 -0000 Received: from unknown (HELO netli.com) (172.17.1.38) by mx01-pal-lan.netli.lan with SMTP; 22 Apr 2003 17:59:50 -0000 Message-ID: <3EA582C2.1040102@netli.com> Date: Tue, 22 Apr 2003 10:58:26 -0700 From: Lev Walkin Organization: Netli, Inc. User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.2.1) Gecko/20030125 X-Accept-Language: ru, en-us, en MIME-Version: 1.0 To: "Kevin A. Pieckiel" References: <20030418214013.GA65290@pacer.dmz.smartrafficenter.org> In-Reply-To: <20030418214013.GA65290@pacer.dmz.smartrafficenter.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org Subject: Re: kqueue events X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 17:59:54 -0000 Kevin A. Pieckiel wrote: > Will the kqueue interface work with pthread ID's, or is it limited > only to system process ID's? If it doesn't work with pthread ID's, > how much trouble is it to modify them and add a pthread ID filter? What are you trying to achieve, by the way? Basically, for the FBSD versions < 5.0 there are two forms of threads available: basic (libc_r) pthreads and linuxthreads from ports. The first type (user-level threads) does the context switching and all the relevant thread management stuff in the user space, so kernel just doesn't have enough information to supply any kind of per-thread-ID notifications with kqueue system call. However, kqueue wrapper in libc_r could be enhanced to support this kind of stuff (it would be a purely user-level library hack). The second type (rfork()-based) is slightly better for you: kqueue should support this natively (system pids are different per each "thread"), and you don't have to modify any default libraries and/or kernel. For 5.0 it seems to be quite a bit more complicated task in every respect. -- Lev Walkin vlm@netli.com