From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by yquem.inria.fr (Postfix) with ESMTP id 23B81BB84 for ; Thu, 11 Sep 2008 18:31:22 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmsBACzkyEhKfSwejWdsb2JhbACDD48YPgEBAQEJAwgJDwWfBIZTAQKEAg X-IronPort-AV: E=Sophos;i="4.32,381,1217800800"; d="scan'208";a="29074953" Received: from yx-out-2324.google.com ([74.125.44.30]) by mail4-smtp-sop.national.inria.fr with ESMTP; 11 Sep 2008 18:31:21 +0200 Received: by yx-out-2324.google.com with SMTP id 3so159323yxj.3 for ; Thu, 11 Sep 2008 09:31:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=DTlVuGa28KrNX5AJWL4j37ecRhO1ETfOttnrtv282WA=; b=ADrKDXhC3c7C7ogQivbOexYbXX+eD/4895AMwqvRwMTpFdZvfI4dMvemM9S3TNmE8s dmk4GH9U4Nk6N9Fo5e/6ZtITnKSoif0vVWHDlUJIbPaUPU3UrVaSMBC5FLR6L9cxR4Z/ udZiwYeAFDgyZZX/MBMCjTrZmbN2ZHkk+3n3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=JHFCay7bKA38tdXVZ/zUWfnkTWEHyQb6Id8Obk32IA7r3aPVGnpFBkmP7rVLUDnlGQ 2Lsp9gr3k94vW9N9gjwkwmezv3d9PFm9HW7QITz9MSd0OpAiVQcOK1kLnVsXDSJmklnQ S5UbXkNat9rWvojIiSWKScWXVfU3HZzqRNMD4= Received: by 10.142.180.19 with SMTP id c19mr1011155wff.263.1221150679919; Thu, 11 Sep 2008 09:31:19 -0700 (PDT) Received: by 10.143.35.6 with HTTP; Thu, 11 Sep 2008 09:31:19 -0700 (PDT) Message-ID: Date: Thu, 11 Sep 2008 12:31:19 -0400 From: "Markus Mottl" To: "Joel Reymont" Subject: Re: [Caml-list] ocamlnet and kernel poll Cc: "=?ISO-8859-1?Q?\"Mattias_Engdeg=E5rd\"?=" , caml-list@yquem.inria.fr In-Reply-To: <43AB5EFE-44FF-47AB-818E-F27DD03823AE@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <01677251-3A8D-4DCA-9E39-7D17FAC92645@gmail.com> <20080911143735.EF7EC29B2A@kicki.hq.vtech> <43AB5EFE-44FF-47AB-818E-F27DD03823AE@gmail.com> X-Spam: no; 0.00; markus:01 mottl:01 markus:01 mottl:01 ocamlnet:01 stubs:01 parallelism:01 ocaml:01 threads:01 threads:01 wrote:01 caml-list:01 functions:01 functions:01 latency:01 On Thu, Sep 11, 2008 at 11:43 AM, Joel Reymont wrote: > Are you suggesting using multiple OS threads within a single process? Yes. > When exactly do you release the lock and how do you perform IO outside of > it? > > How do you determine whether to release the lock or not? Look at our Core-library. It contains a module "Bigstring", which provides many efficient I/O-functions for those. Look at "bigstring_stubs.c", where you'll see how these functions are implemented in C-land, e.g. when the lock gets released, etc. There are functions like e.g. "read_assume_nonblocking", which one can use if one knows for sure that a read cannot block (e.g. after a "select"). Then the function determines whether it's worth/necessary releasing the lock. If, for example, the read is performed into a bigstring which happens to be a memory-mapped file, then the lock will always be released, because if the memory page happens to be on disk you might otherwise experience latency spikes when it's being paged in, since all other threads would temporarily freeze. Same for very large I/O-operations: there the lock would be released, too, to exploit parallelism, improve throughput, and avoid latency spikes. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mottl@gmail.com