From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id E0CA57F75C for ; Mon, 8 Sep 2014 12:45:56 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of modlfo@gmail.com) identity=pra; client-ip=209.85.223.182; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="modlfo@gmail.com"; x-sender="modlfo@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of modlfo@gmail.com designates 209.85.223.182 as permitted sender) identity=mailfrom; client-ip=209.85.223.182; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="modlfo@gmail.com"; x-sender="modlfo@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ie0-f182.google.com) identity=helo; client-ip=209.85.223.182; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="modlfo@gmail.com"; x-sender="postmaster@mail-ie0-f182.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokDAAGIDVTRVd+2m2dsb2JhbABZhDeCfK1gBqBeAYEVFhABAQEBAQYLCwkUKoQEAQEEEhEVCAEbHAIDDAYFCw0CAgUWCwICCQMCAQIBEREBBQEcEwYCAQEeiAsBAxEEAZl+a4swgXKDEIhiChknDWaFdAERAQUOgR6EUIlYFoJjgVMBBJxyh0GLeUGFFGqCTwEBAQ X-IPAS-Result: AokDAAGIDVTRVd+2m2dsb2JhbABZhDeCfK1gBqBeAYEVFhABAQEBAQYLCwkUKoQEAQEEEhEVCAEbHAIDDAYFCw0CAgUWCwICCQMCAQIBEREBBQEcEwYCAQEeiAsBAxEEAZl+a4swgXKDEIhiChknDWaFdAERAQUOgR6EUIlYFoJjgVMBBJxyh0GLeUGFFGqCTwEBAQ X-IronPort-AV: E=Sophos;i="5.04,486,1406584800"; d="scan'208";a="78126262" Received: from mail-ie0-f182.google.com ([209.85.223.182]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Sep 2014 12:45:56 +0200 Received: by mail-ie0-f182.google.com with SMTP id tr6so1033188ieb.13 for ; Mon, 08 Sep 2014 03:45:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=D176VPS4C1CC+9uo4R9pIh8IQ30dY4xUiHMLtqDPWoI=; b=FxPnftk0kYctfb/NzqjBtDUo6WYJUl8VU4ZtNRrVs/ZPm5fEDLHFmbFNRFdZHO2pKA nbNEMZkXrmfHcUvy8SRhcdLYjtp3vnmm17bZ2K+3icqpbI9zLYTaxHx6hN0obMR81ueM uapU2/3SY5/iP0KZSjZ37joGftlkhG00FCLSh6LwbTF0GpSHPGl5IAO7ackQp0pz/SWo Ahq9al88nC1KLo+rcwOZihxxu3jg3IRm6HgQc/H1OnXrQvPEi/auly6Hcf+mduQPAD1g eNzpfHVftHxBH3yp/Jc+uvqV6ixnPHQUy6kUR9k1cBByP6wF7XgxECJP25fBgUGSrXSi dalA== X-Received: by 10.50.13.69 with SMTP id f5mr9008791igc.26.1410173155206; Mon, 08 Sep 2014 03:45:55 -0700 (PDT) Received: from [10.10.156.126] ([94.136.92.233]) by mx.google.com with ESMTPSA id ky8sm8654214igb.16.2014.09.08.03.45.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Sep 2014 03:45:54 -0700 (PDT) Message-ID: <540D88DF.9010804@gmail.com> Date: Mon, 08 Sep 2014 12:45:51 +0200 From: Leonardo Laguna Ruiz User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: caml-list@inria.fr References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Caml-list] Multicore runtime Hi, I have only one question. Will it work on the windows MSVC port? Leonardo On 9/8/2014 12:05 PM, Stephen Dolan wrote: > On Sun, Sep 7, 2014 at 10:47 PM, Jiten Pathy wrote: >> Hello, >> Nice work by stephen et al. on multicore runtime. Just had some questions:- >> 1. What's the mapping between os threads and domains? > One-to-one. > >> 2. How does blocked fibers on a domain work? Does a blocked os thread >> running a fiber creates new os thread for that domain? > Fibers blocked on internal events (e.g. waiting for another fiber to > fill in an mvar) don't block anything - the system just runs some > other fiber. Fibers blocked on long-running / blocking C calls do > block the domain. If they do so for long enough, other fibers on the > domain will be moved to active domains. > > Generally, we're going to try to avoid blocking C calls and instead > use select/poll/kqueue/epoll to handle blocking I/O. From the fiber's > point of view, this looks like normal blocking I/O, except if a system > call returns EWOULDBLOCK we'll switch to another fiber until the I/O > is ready. > >> 3. Is there anyway for a fiber to relinquish a domain, for the ones >> that do loops for a significant period of time without blocking other >> fibers? > There's a yield function that can be called explicitly. Currently, > compute-bound fibers that don't yield do tie up a domain. > > Stephen >