From owner-freebsd-threads@FreeBSD.ORG Sun Mar 18 21:37:52 2012 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 11BAA106564A for ; Sun, 18 Mar 2012 21:37:52 +0000 (UTC) (envelope-from cmeerw@cmeerw.org) Received: from edge.cmeerw.net (edge.cmeerw.net [IPv6:2001:1608:10:3::7]) by mx1.freebsd.org (Postfix) with ESMTP id 9C4508FC12 for ; Sun, 18 Mar 2012 21:37:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cmeerw.org; s=dkim; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=tUWQ8E5bY6XMDqx7ig8CmC49JKMrgIWEvK3pDifhWQE=; b=UIbAPzVSa65EljvdidRRGgWtVldePC36/ZI3tvv7K0mUOL7M7ReY/BZ+wyRFKmkolCLuA9vMoBMTeVw4+jTWrgi5ZIG1mSBtynqfqEBrpSpjU4+UJ/O1KCmYQVs5eqkkoBlkTrxsvkNhURU4wst1+p9FFpN+mnd7jQMoJ2OVaLk=; Received: from cmeerw by edge.cmeerw.net with local (Exim 4.77) (envelope-from ) id 1S9NnR-0006CO-Gm; Sun, 18 Mar 2012 22:37:49 +0100 Date: Sun, 18 Mar 2012 22:37:49 +0100 From: Christof Meerwald To: freebsd-threads@freebsd.org Message-ID: <20120318213749.GQ843@edge.cmeerw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-Key: 1024D/2B10BE68, 1998-06-29 X-PGP-Fingerprint: 0289 5466 C1F5 B03C DBA7 6304 8CAF 9782 2B10 BE68 User-Agent: Mutt/1.5.20 (2009-06-14) Subject: kevent and multiple worker threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 21:37:52 -0000 Hi, I am trying to figure out how kqueue/kevent works in a multi-threaded environment. So I have created a small test program (http://svn.cmeerw.net/src/nginetd/trunk/test/kqtest.cc) that creates a socketpair and send 4-byte messages between the 2 sockets. There is only ever 1 message in transit, but there can be multiple threads waiting for event notification using kevent. Note that I have only been able to test this inside a KVM virtual machine with FreeBSD 9.0 on a dual-core AMD64 laptop. But what I find extremely interesting is that the time seems to increase exponentially with the number of worker threads, e.g. I get (the first argument is the number of worker threads and the second is the number of iterations): $ ./kqtest 1 100000 0.508513 $ ./kqtest 2 100000 1.377444 $ ./kqtest 4 100000 2.533485 $ ./kqtest 8 100000 12.305741 BTW, I have also tested in with NetBSD 6.0 BETA on the same machine (also inside a KVM virtual machine) and there the results look different: $ ./kqtest 1 100000 0.480187 $ ./kqtest 2 100000 1.875658 $ ./kqtest 4 100000 1.552574 $ ./kqtest 8 100000 2.024548 $ ./kqtest 16 100000 1.951622 While there is a big difference on NetBSD between 1 and 2 worker threads, the run time then is roughly stable. There is also a Linux version (using epoll) of this test program (http://svn.cmeerw.net/src/nginetd/trunk/test/eptest.cc). There the timings are much more stable (but this is the actual host operating system, so no virtual machine) although the single-threaded case is actually slower than on NetBSD/FreeBSD: $ ./eptest 1 100000 0.635127 $ ./eptest 2 100000 0.827467 $ ./eptest 4 100000 0.909760 $ ./eptest 8 100000 0.929008 $ ./eptest 16 100000 1.010422 So, I guess my first question is: is this just caused by running it inside a KVM virtual machine or could someone be so nice and try to reproduce this behaviour on actual hardware? Am I doing something completely stupid in the source code? As far as I can tell, when data is available on one of the sockets, only one threads gets woken up (so at least from the user space side the behaviour looks reasonable). Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org From owner-freebsd-threads@FreeBSD.ORG Sun Mar 18 22:30:12 2012 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BC4E106566B for ; Sun, 18 Mar 2012 22:30:12 +0000 (UTC) (envelope-from gofdt-freebsd-threads@m.gmane.org) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by mx1.freebsd.org (Postfix) with ESMTP id 162608FC12 for ; Sun, 18 Mar 2012 22:30:11 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1S9Obz-0002dY-BL for freebsd-threads@freebsd.org; Sun, 18 Mar 2012 23:30:03 +0100 Received: from 201.82.200.35 ([201.82.200.35]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Mar 2012 23:30:03 +0100 Received: from rakuco by 201.82.200.35 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 18 Mar 2012 23:30:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-threads@freebsd.org From: Raphael Kubo da Costa Date: Sun, 18 Mar 2012 19:24:44 -0300 Lines: 18 Message-ID: <87haxlh7ir.fsf@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: 201.82.200.35 User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/24.0.93 (berkeley-unix) Cancel-Lock: sha1:4FnQSORDdR471ZkTFLdswj6MD5Y= Cc: freebsd-standards@freebsd.org Subject: Should __clockid_t be used instead of clockid_t in pthread.h? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Mar 2012 22:30:12 -0000 Hi there. I'm trying to build an unstable glib version here, and one of their tests fails to build due to them #defining _POSIX_C_SOURCE to 0 and then #including , which produces the following error on my 8-STABLE machine: /usr/include/pthread.h:184: error: expected declaration specifiers or '...' before 'clockid_t' /usr/include/pthread.h:187: error: expected declaration specifiers or '...' before 'clockid_t' /usr/include/pthread.h:203: error: expected declaration specifiers or '...' before 'clockid_t' pthread.h gets its definition of clockid_t from time.h, but time.h only creates the typedef if __POSIX_VISIBLE is >= 199309. Using __clockid_t instead of clockid_t in the function prototypes works fine. Should the prototypes be changed? Thanks. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 19 09:02:29 2012 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 0615B1065674; Mon, 19 Mar 2012 09:02:29 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail04.syd.optusnet.com.au (mail04.syd.optusnet.com.au [211.29.132.185]) by mx1.freebsd.org (Postfix) with ESMTP id 6DD588FC0A; Mon, 19 Mar 2012 09:02:27 +0000 (UTC) Received: from c211-30-171-136.carlnfd1.nsw.optusnet.com.au (c211-30-171-136.carlnfd1.nsw.optusnet.com.au [211.30.171.136]) by mail04.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q2J92B0P004569 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Mar 2012 20:02:20 +1100 Date: Mon, 19 Mar 2012 20:02:11 +1100 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Raphael Kubo da Costa In-Reply-To: <87haxlh7ir.fsf@FreeBSD.org> Message-ID: <20120319194821.H1024@besplex.bde.org> References: <87haxlh7ir.fsf@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-standards@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: Should __clockid_t be used instead of clockid_t in pthread.h? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 09:02:29 -0000 On Sun, 18 Mar 2012, Raphael Kubo da Costa wrote: > Hi there. > > I'm trying to build an unstable glib version here, and one of their > tests fails to build due to them #defining _POSIX_C_SOURCE to 0 and > then #including , which produces the following error on my > 8-STABLE machine: This gives undefined behaviour. > /usr/include/pthread.h:184: error: expected declaration specifiers or '...' before 'clockid_t' > /usr/include/pthread.h:187: error: expected declaration specifiers or '...' before 'clockid_t' > /usr/include/pthread.h:203: error: expected declaration specifiers or '...' before 'clockid_t' > > pthread.h gets its definition of clockid_t from time.h, but time.h only > creates the typedef if __POSIX_VISIBLE is >= 199309. Using __clockid_t > instead of clockid_t in the function prototypes works fine. > > Should the prototypes be changed? time.h is a standard C header, so not defining clockid_t in it when POSIX extensions are disabled is correct. pthread.h is a not-so-old POSIX header, so it can assume that __POSIX_VISIBLE is >= 199309. Including it when POSIX is not visible, or when only an older version of POSIX is visible, is just nonsense and can have any result, like the one here. While using __clockid_t in in might make it sort of work, it would remain quite broken. POSIX requires that pthread.h shall make all the namespace pollution in time.h (and some other headers) visible. This is a bug in POSIX. It actually requires that pthread.h shall make all the [POSIX] symbols in time.h visible. pthread.h just includes time.h to get all of these symbols, and becomes broken if ones like clockid_t are not declared. If pthread.h is actually used, then programs using it will actually need some of the symbols like clockid_t from time.h and break when they don't explicitly include time.h. Bruce From owner-freebsd-threads@FreeBSD.ORG Mon Mar 19 11:07:24 2012 Return-Path: Delivered-To: freebsd-threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1ACAD106566C for ; Mon, 19 Mar 2012 11:07:24 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id DF3078FC19 for ; Mon, 19 Mar 2012 11:07:23 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id q2JB7NBO033735 for ; Mon, 19 Mar 2012 11:07:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id q2JB7N2V033733 for freebsd-threads@FreeBSD.org; Mon, 19 Mar 2012 11:07:23 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 19 Mar 2012 11:07:23 GMT Message-Id: <201203191107.q2JB7N2V033733@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-threads@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-threads@FreeBSD.org X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 11:07:24 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o threa/165173 threads [build] clang buildworld breaks libthr o threa/163512 threads libc defaults to single threaded o threa/160708 threads possible security problem with RLIMIT_VMEM o threa/150959 threads [libc] Stub pthread_once in libc should call _libc_onc o threa/148515 threads Memory / syslog strangeness in FreeBSD 8.x ( possible o threa/141721 threads rtprio(1): (id|rt)prio priority resets when new thread o threa/135673 threads databases/mysql50-server - MySQL query lock-ups on 7.2 o threa/128922 threads threads hang with xorg running o threa/122923 threads 'nice' does not prevent background process from steali o threa/121336 threads lang/neko threading ok on UP, broken on SMP (FreeBSD 7 o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/110636 threads [request] gdb(1): using gdb with multi thread applicat o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/101323 threads [patch] fork(2) in threaded programs broken. s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/79683 threads svctcp_create() fails if multiple threads call at the s threa/76694 threads fork cause hang in dup()/close() function in child (-l s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/34536 threads accept() blocks other threads s threa/30464 threads [patch] pthread mutex attributes -- pshared 23 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Mar 19 17:33:55 2012 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7B925106564A; Mon, 19 Mar 2012 17:33:55 +0000 (UTC) (envelope-from kubito@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1E94E8FC18; Mon, 19 Mar 2012 17:33:54 +0000 (UTC) Received: by yenl9 with SMTP id l9so6845349yen.13 for ; Mon, 19 Mar 2012 10:33:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=4UsupB9tDCSpvMNaibXUq7JZG4Wx2MShhny1ffNm0KE=; b=Qizbu6HKWzABz3Xu/r/wbKMyic7WLw4ifPAsa0OcEWKVRTLwwhIgPEsnqVjZnibeB2 yHA0QEIQQX9Ii3BP0mXmaaQ+kCtQWleOJDe9Z40z8sXzVCxPrRfcSK3aMTWJGJ/p1Q7r DcjhPHH8K1Lq22cSFH+nxGammNdBVCV25yxIK68BtwRc0M661I3NHmuQ9pWbwUm6SrAx 7i3NODuY1UqGit8hWecjsyAHt1/GunzUIlVYJT6a+rayI9QAdrUP6Tiw9xdXULrhLBQS hr3gAW+vpkXHIRkuRupsNXys8QG4msZxBKZjeZT9fr1OyYOym8stodKEzUZI4TYx06JZ 99jQ== Received: by 10.60.18.137 with SMTP id w9mr14666398oed.7.1332178434262; Mon, 19 Mar 2012 10:33:54 -0700 (PDT) Received: from rachacuca.gmail.com (li113-135.members.linode.com. [69.164.198.135]) by mx.google.com with ESMTPS id 8sm13663132obv.19.2012.03.19.10.33.52 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 19 Mar 2012 10:33:53 -0700 (PDT) Sender: Raphael Kubo da Costa From: Raphael Kubo da Costa To: Bruce Evans References: <87haxlh7ir.fsf@FreeBSD.org> <20120319194821.H1024@besplex.bde.org> Date: Mon, 19 Mar 2012 14:34:51 -0300 In-Reply-To: <20120319194821.H1024@besplex.bde.org> (Bruce Evans's message of "Mon, 19 Mar 2012 20:02:11 +1100 (EST)") Message-ID: <83haxk8pfo.fsf@FreeBSD.org> User-Agent: Gnus/5.130004 (Ma Gnus v0.4) Emacs/23.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Cc: freebsd-standards@FreeBSD.org, freebsd-threads@FreeBSD.org Subject: Re: Should __clockid_t be used instead of clockid_t in pthread.h? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 17:33:55 -0000 Bruce Evans writes: > On Sun, 18 Mar 2012, Raphael Kubo da Costa wrote: > >> Hi there. >> >> I'm trying to build an unstable glib version here, and one of their >> tests fails to build due to them #defining _POSIX_C_SOURCE to 0 and >> then #including , which produces the following error on my >> 8-STABLE machine: > > This gives undefined behaviour. > >> /usr/include/pthread.h:184: error: expected declaration specifiers or '...' before 'clockid_t' >> /usr/include/pthread.h:187: error: expected declaration specifiers or '...' before 'clockid_t' >> /usr/include/pthread.h:203: error: expected declaration specifiers or '...' before 'clockid_t' >> >> pthread.h gets its definition of clockid_t from time.h, but time.h only >> creates the typedef if __POSIX_VISIBLE is >= 199309. Using __clockid_t >> instead of clockid_t in the function prototypes works fine. >> >> Should the prototypes be changed? > > time.h is a standard C header, so not defining clockid_t in it when POSIX > extensions are disabled is correct. > > pthread.h is a not-so-old POSIX header, so it can assume that > __POSIX_VISIBLE is >= 199309. Including it when POSIX is not visible, > or when only an older version of POSIX is visible, is just nonsense > and can have any result, like the one here. While using __clockid_t > in in might make it sort of work, it would remain quite broken. POSIX > requires that pthread.h shall make all the namespace pollution in > time.h (and some other headers) visible. This is a bug in POSIX. It > actually requires that pthread.h shall make all the [POSIX] symbols > in time.h visible. pthread.h just includes time.h to get all of these > symbols, and becomes broken if ones like clockid_t are not declared. > If pthread.h is actually used, then programs using it will actually > need some of the symbols like clockid_t from time.h and break when > they don't explicitly include time.h. Thank you for the detailed explanation. I've filed a bug in glib's Bugzilla [1] with a proposed fix that should work on both FreeBSD and Linux. [1] https://bugzilla.gnome.org/show_bug.cgi?id=672406 From owner-freebsd-threads@FreeBSD.ORG Mon Mar 19 18:09:46 2012 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2C535106566C; Mon, 19 Mar 2012 18:09:46 +0000 (UTC) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.freebsd.org (Postfix) with ESMTP id 89E2D8FC0C; Mon, 19 Mar 2012 18:09:45 +0000 (UTC) Received: from khavrinen.csail.mit.edu (localhost [127.0.0.1]) by khavrinen.csail.mit.edu (8.14.4/8.14.4) with ESMTP id q2JI9c6s056656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL CN=khavrinen.csail.mit.edu issuer=Client+20CA); Mon, 19 Mar 2012 14:09:39 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.14.4/8.14.4/Submit) id q2JI9csD056653; Mon, 19 Mar 2012 14:09:38 -0400 (EDT) (envelope-from wollman) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20327.30306.939303.433270@khavrinen.csail.mit.edu> Date: Mon, 19 Mar 2012 14:09:38 -0400 From: Garrett Wollman To: Raphael Kubo da Costa In-Reply-To: <83haxk8pfo.fsf@FreeBSD.org> References: <87haxlh7ir.fsf@FreeBSD.org> <20120319194821.H1024@besplex.bde.org> <83haxk8pfo.fsf@FreeBSD.org> X-Mailer: VM 7.17 under 21.4 (patch 22) "Instant Classic" XEmacs Lucid X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (khavrinen.csail.mit.edu [127.0.0.1]); Mon, 19 Mar 2012 14:09:39 -0400 (EDT) Cc: freebsd-standards@freebsd.org, freebsd-threads@freebsd.org Subject: Re: Should __clockid_t be used instead of clockid_t in pthread.h? X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Mar 2012 18:09:46 -0000 < said: > Thank you for the detailed explanation. I've filed a bug in glib's > Bugzilla [1] with a proposed fix that should work on both FreeBSD and > Linux. Unfortunately, your proposed fix has the result of requesting a *strict* POSIX environment, so applications that depend on system interfaces that were not in the 1993 threading amendments will no longer compile. Maybe this doesn't matter in the specific case of your testing framework, but it's not a universally correct solution. -GAWollman From owner-freebsd-threads@FreeBSD.ORG Wed Mar 21 07:13:17 2012 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 23582106567B for ; Wed, 21 Mar 2012 07:13:17 +0000 (UTC) (envelope-from cmeerw@cmeerw.org) Received: from edge.cmeerw.net (edge.cmeerw.net [IPv6:2001:1608:10:3::7]) by mx1.freebsd.org (Postfix) with ESMTP id A73978FC20 for ; Wed, 21 Mar 2012 07:13:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cmeerw.org; s=dkim; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID:Subject:To:From:Date; bh=0RQ4WjGoZu0515Ouhr8rrDRifHnl3U38oVGRJJ+XOoY=; b=oDIA/qvL+su2aeQB9y/uoic2Bde0TsKeK9gJ1eoIKusdZmNlVZBoOZtp4TvZpPCtvBAr4Kytam59pC1zHVueuMnis+WniY9zGfykW9+E0N0RZa0T65u5TwXa7unDIcq7I0NaWScgBFOtqPXQwApducclpjT/TgrcH9vfTbwpyp0=; Received: from cmeerw by edge.cmeerw.net with local (Exim 4.77) (envelope-from ) id 1SAFjN-0008H4-IE; Wed, 21 Mar 2012 08:13:13 +0100 Date: Wed, 21 Mar 2012 08:13:13 +0100 From: Christof Meerwald To: freebsd-threads@freebsd.org Message-ID: <20120321071313.GA30458@edge.cmeerw.net> References: <20120318213749.GQ843@edge.cmeerw.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120318213749.GQ843@edge.cmeerw.net> X-PGP-Key: 1024D/2B10BE68, 1998-06-29 X-PGP-Fingerprint: 0289 5466 C1F5 B03C DBA7 6304 8CAF 9782 2B10 BE68 User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: kevent and multiple worker threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Mar 2012 07:13:17 -0000 On Sun, Mar 18, 2012 at 10:37:49PM +0100, Christof Meerwald wrote: > I am trying to figure out how kqueue/kevent works in a multi-threaded > environment. So I have created a small test program > (http://svn.cmeerw.net/src/nginetd/trunk/test/kqtest.cc) that creates > a socketpair and send 4-byte messages between the 2 sockets. There is > only ever 1 message in transit, but there can be multiple threads > waiting for event notification using kevent. Ok, it looks like it has something to do with the size of the eventlist I am passing in - if I call kevent with nevents=16 instead of nevents=1 I get much more reasonable results on FreeBSD. The surprising thing here, of course, is that kevent will only ever return 1 event (as there is only 1 message in transit), so I am not sure why the size of the eventlist would make a difference. Christof -- http://cmeerw.org sip:cmeerw at cmeerw.org mailto:cmeerw at cmeerw.org xmpp:cmeerw at cmeerw.org