From owner-freebsd-threads@FreeBSD.ORG Mon Oct 22 11:07:17 2007 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6A7E616A420 for ; Mon, 22 Oct 2007 11:07:17 +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 58ADC13C48E for ; Mon, 22 Oct 2007 11:07:17 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.1/8.14.1) with ESMTP id l9MB7HZU080120 for ; Mon, 22 Oct 2007 11:07:17 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.1/8.14.1/Submit) id l9MB7Gfb080116 for freebsd-threads@FreeBSD.org; Mon, 22 Oct 2007 11:07:16 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 22 Oct 2007 11:07:16 GMT Message-Id: <200710221107.l9MB7Gfb080116@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, 22 Oct 2007 11:07:17 -0000 Current FreeBSD problem reports Critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s threa/76690 threads fork hang in child for -lc_r 1 problem total. Serious problems S Tracker Resp. Description -------------------------------------------------------------------------------- o kern/20016 threads pthreads: Cannot set scheduling timer/Cannot set virtu s threa/24472 threads libc_r does not honor SO_SNDTIMEO/SO_RCVTIMEO socket o s threa/24632 threads libc_r delicate deviation from libc in handling SIGCHL s bin/32295 threads pthread dont dequeue signals s threa/34536 threads accept() blocks other threads o kern/38549 threads the procces compiled whith pthread stopped in pthread_ s threa/39922 threads [threads] [patch] Threaded applications executed with s threa/48856 threads Setting SIGCHLD to SIG_IGN still leaves zombies under s threa/49087 threads Signals lost in programs linked with libc_r s kern/64313 threads FreeBSD (OpenBSD) pthread implicit set/unset O_NONBLOC o threa/70975 threads unexpected and unreliable behaviour when using SYSV se o threa/72429 threads threads blocked in stdio (fgets, etc) are not cancella o threa/72953 threads fork() unblocks blocked signals w/o PTHREAD_SCOPE_SYST o threa/75273 threads FBSD 5.3 libpthread (KSE) bug o threa/75374 threads pthread_kill() ignores SA_SIGINFO flag s threa/76694 threads fork cause hang in dup()/close() function in child (-l o threa/79683 threads svctcp_create() fails if multiple threads call at the o threa/80435 threads panic on high loads o threa/83914 threads [libc] popen() doesn't work in static threaded program s threa/84483 threads problems with devel/nspr and -lc_r on 4.x o threa/85160 threads [libthr] [patch] libobjc + libpthread/libthr crash pro o kern/91266 threads [threads] Trying sleep, but thread marked as sleeping s threa/94467 threads send(), sendto() and sendmsg() are not correct in libc s threa/100815 threads FBSD 5.5 broke nanosleep in libc_r o threa/101323 threads fork(2) in threaded programs broken. o threa/103975 threads Implicit loading/unloading of libpthread.so may crash o threa/110636 threads gdb(1): using gdb with multi thread application with l o threa/113666 threads misc/shared-mime-info doesn't install, can't find thre 28 problems total. Non-critical problems S Tracker Resp. Description -------------------------------------------------------------------------------- s kern/19247 threads uthread_sigaction.c does not do anything wrt SA_NOCLDW s kern/22190 threads A threaded read(2) from a socketpair(2) fd can sometim s threa/30464 threads pthread mutex attributes -- pshared s threa/37676 threads libc_r: msgsnd(), msgrcv(), pread(), pwrite() need wra s threa/40671 threads pthread_cancel doesn't remove thread from condition qu s threa/69020 threads pthreads library leaks _gc_mutex o threa/79887 threads [patch] freopen() isn't thread-safe o threa/80992 threads abort() sometimes not caught by gdb depending on threa o threa/110306 threads apache 2.0 segmentation violation when calling gethost o threa/115211 threads pthread_atfork misbehaves in initial thread o threa/116668 threads can no longer use jdk15 with libthr on -stable SMP 11 problems total. From owner-freebsd-threads@FreeBSD.ORG Mon Oct 22 18:59:43 2007 Return-Path: Delivered-To: threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4E71C16A417 for ; Mon, 22 Oct 2007 18:59:43 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.freebsd.org (Postfix) with ESMTP id 3250A13C4BD for ; Mon, 22 Oct 2007 18:59:42 +0000 (UTC) (envelope-from bright@elvis.mu.org) Received: by elvis.mu.org (Postfix, from userid 1192) id 0CA3B1A4D82; Mon, 22 Oct 2007 11:42:04 -0700 (PDT) Date: Mon, 22 Oct 2007 11:42:04 -0700 From: Alfred Perlstein To: threads@freebsd.org Message-ID: <20071022184203.GU31826@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Cc: Subject: Lack of usable thread_exit(9) api painful. 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, 22 Oct 2007 18:59:43 -0000 Hey guys, I'm trying to develop a feature here and I'm getting hit pretty hard by not having a very useable API for doing things when a thread is torn down. I basically need to do a vsunlock(9) on some of the process's memory, however doing that is proving difficult as thread_exit(9) requires sched and proc locks going in which appear to need to be held throughout the function in order to function properly. Does anyone have any ideas? I'm probably going to hook into the reaper thread that kills thread contexts, and hopefully that should be enough to get it right, but I'm not 100% sure. ouch. -- - Alfred Perlstein From owner-freebsd-threads@FreeBSD.ORG Fri Oct 26 07:09:07 2007 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 4275F16A418; Fri, 26 Oct 2007 07:09:07 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (relay0.rambler.ru [81.19.66.187]) by mx1.freebsd.org (Postfix) with ESMTP id EF00513C4A7; Fri, 26 Oct 2007 07:09:06 +0000 (UTC) (envelope-from is@rambler-co.ru) Received: from relay0.rambler.ru (localhost [127.0.0.1]) by relay0.rambler.ru (Postfix) with ESMTP id C1E7B71F4; Fri, 26 Oct 2007 10:38:35 +0400 (MSD) Received: from localhost (is1.park.rambler.ru [81.19.64.121]) by relay0.rambler.ru (Postfix) with ESMTP id 8409E71EA; Fri, 26 Oct 2007 10:38:35 +0400 (MSD) Date: Fri, 26 Oct 2007 10:38:22 +0400 From: Igor Sysoev To: freebsd-threads@freebsd.org Message-ID: <20071026063822.GA91344@rambler-co.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) X-Virus-Scanned: No virus found Cc: David Xu Subject: kqueue based thread pool 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: Fri, 26 Oct 2007 07:09:07 -0000 The modern threads implementation works fine with program that requires fair threads scheduling, like Apache and MySQL. However, there are programs (like varnish) that use FSM and thread pool. The threads allow to run on SMP and reduce blocking on disk I/O. These programs use an acceptor/listener thread and worker pool threads. In this model it's preferable to have one RUNnable worker thread per CPU and to start next one only when the current thread blocks. Also, when scheduler chooses next thread to run it should get the more recently run (cache hot) thread instead of fair scheduling. It's good to have some idle threads in pool, those run very seldom when active threads are blocked on I/O, etc. Just wonder whether current scheduler is easy extendable to create thread pool controlled by kqueue: that is the kernel acts as acceptor/listener thread that wakes up worker threads waiting in kevent() ? -- Igor Sysoev http://sysoev.ru/en/