From owner-freebsd-threads@FreeBSD.ORG Thu Mar 3 08:44:46 2005 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D42716A4CE for ; Thu, 3 Mar 2005 08:44:46 +0000 (GMT) Received: from mail.emict.com (brig.emict.com [212.90.172.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E14D43D41 for ; Thu, 3 Mar 2005 08:44:43 +0000 (GMT) (envelope-from andrit@ukr.net) Received: from BORJA (unknown [203.199.120.221]) by mail.emict.com (Postfix) with ESMTP id 11B24337C3 for ; Thu, 3 Mar 2005 10:44:39 +0200 (EET) Message-ID: <010b01c51fcd$3d0dabb0$090210ac@BORJA> From: "Andriy Tkachuk" To: References: <000b01c51fbb$4189ea30$090210ac@BORJA> <005201c51fc2$d8676b60$090210ac@BORJA> <4226C7B6.4060901@freebsd.org> Date: Thu, 3 Mar 2005 14:14:30 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: patch for threads/76690 - critical - fork hang in child for-lc_r X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2005 08:44:46 -0000 actually, this test prog was written after there were problems with multithreaded domestic application server, that was tested under load. this one is using intensively hash manipulations. it is develped for redhat 7.3 and tested there. it was interesting for me, how it will behaves on fbsd in linux emulation - it was fine (note: there is linix pthreads). then we wrote this test prog to investigate the threads with heap manipulations sumultaneousely. It was interesting for me to investigate the same in freebsd. that's how it was. :) > Hmm, libc_r and libpthread handle spinlock differently which malloc > uses to protect itself, some real world benchmarks are better than this. > > David Xu