From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id 4DB35BBA7 for ; Wed, 8 Feb 2006 15:43:56 +0100 (CET) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.13.0/8.13.0) with ESMTP id k18EhtUN029742 for ; Wed, 8 Feb 2006 15:43:55 +0100 Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id PAA09215 for ; Wed, 8 Feb 2006 15:43:55 +0100 (MET) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.204]) by nez-perce.inria.fr (8.13.0/8.13.0) with ESMTP id k18EhsAb015493 for ; Wed, 8 Feb 2006 15:43:54 +0100 Received: by xproxy.gmail.com with SMTP id h28so1993275wxd for ; Wed, 08 Feb 2006 06:43:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YYuevPt1tOuw4a30pAJUdTdG+RYHv8KEdHoxRzqHVp2UY6fu6qZC4QNZvjl7/+ehX5ReRvzn2O9QybwmbqtJEUOv4hJbhG9T/QmTKp2esXbWS9gALP6a9zrVqUwQEfQzHYu3k5XYj1EEYqpxJKIg2d1r8lfqSX9lDA0azdRNiKU= Received: by 10.70.45.14 with SMTP id s14mr8714725wxs; Wed, 08 Feb 2006 06:43:35 -0800 (PST) Received: by 10.70.56.4 with HTTP; Wed, 8 Feb 2006 06:43:35 -0800 (PST) Message-ID: Date: Wed, 8 Feb 2006 09:43:35 -0500 From: Markus Mottl To: rick@eltopia.com Subject: Re: [Caml-list] Re: async networking Cc: caml-list@inria.fr In-Reply-To: <1139372282.10092.10.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1139129530.15565.3.camel@localhost.localdomain> <1139160736.10812.3.camel@localhost.localdomain> <1139288125.19213.36.camel@rosella> <1139347775.10092.6.camel@localhost.localdomain> <1139372282.10092.10.camel@localhost.localdomain> X-Miltered: at concorde with ID 43EA03AB.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Miltered: at nez-perce with ID 43EA03AA.002 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 caml-list:01 async:01 threads:01 ocaml:01 reschedule:98 wrote:01 passing:01 passing:01 thread:02 thread:02 data:02 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on yquem.inria.fr X-Spam-Level: ** X-Spam-Status: No, score=2.5 required=5.0 tests=BANG_EXERCISE,INFO_TLD, RCVD_BY_IP autolearn=disabled version=3.0.3 On 2/7/06, Rick Richardson wrote: > I technically don't need to officially reschedule.. since they will all > be doing the same thing, I'll sleep the thread, then when data becomes > available pass it the new fd and wake it up. A simple queue would be > fine for that. You had mentioned that you mostly care about performance in an environment with low data volume and a high number of transactions (connections). Passing off data between threads requires a context-switch, which is going to kill your performance if you have to do that very often (as is the case here). It would be better to attempt "straight-through processing" (STP): let the thread that initially received the data execute the job, and only if this would take too long (e.g. because it might block) should you consider passing off the work to a helper thread. In that case it would be advisable to use two queues if you want to reduce the number of locks required to access new jobs. By using STP you can quite likely improve performance by an order of magnitude for your kind of problem. We have implemented a library for STP and are probably going to release it to the general public within the next couple of weeks anyway, but the hints above might still be useful to you if you want to implement a solution yourself (good exercise! ;). Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com