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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 666DF7F75C for ; Mon, 8 Sep 2014 12:05:55 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of stedolan@stedolan.net) identity=pra; client-ip=209.85.215.48; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="stedolan@stedolan.net"; x-sender="stedolan@stedolan.net"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of stedolan@stedolan.net) identity=mailfrom; client-ip=209.85.215.48; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="stedolan@stedolan.net"; x-sender="stedolan@stedolan.net"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-la0-f48.google.com) identity=helo; client-ip=209.85.215.48; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="stedolan@stedolan.net"; x-sender="postmaster@mail-la0-f48.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlABABt/DVTRVdcwm2dsb2JhbABZhDcEgni1BppNCBYQAQEBAQEGCwsJFCqEAwEBAQMBEhFWBQsBCgsDCgICJgICIhIBBQEcBhMIGogYCJoYa4swjxOGAwEXCoEikSGBUwEEkkGKMZM6GCmFE2uBSIEHAQEB X-IPAS-Result: AlABABt/DVTRVdcwm2dsb2JhbABZhDcEgni1BppNCBYQAQEBAQEGCwsJFCqEAwEBAQMBEhFWBQsBCgsDCgICJgICIhIBBQEcBhMIGogYCJoYa4swjxOGAwEXCoEikSGBUwEEkkGKMZM6GCmFE2uBSIEHAQEB X-IronPort-AV: E=Sophos;i="5.04,486,1406584800"; d="scan'208";a="93495771" Received: from mail-la0-f48.google.com ([209.85.215.48]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Sep 2014 12:05:34 +0200 Received: by mail-la0-f48.google.com with SMTP id ty20so4932816lab.7 for ; Mon, 08 Sep 2014 03:05:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=29CLnCErBuSM4HXjh9Is6evO816pXyyj+qhwcxyawo0=; b=CVe3P5ey4+lX4LB8tKIeWDkcs+EFm4FImrOMntSziwtB/YezWl0EInchA31sSjKpMf gqzSINVfMgwBaDXOfKr8c+rKaD5qKeILp791YLt73iDcD3sjF4IUV+IRnqSxsQD7WmCX vYI62sWqasoyC7b/DK2mwWwIQjq8ky3J+E8mDoUdiYpG8hAEAe0U1IuHszvSBHID75jK ua7/CQFSkkpSlcxj8Ok/STZPIlkmxuuLVgQISIIlv6MvwDE9yglQoYWK57F/MuWl0zS3 VMVHNm/jwHQXdeo/f364Y6ZIslPVbMCa4vLWP9PGcqfXBqD2AXyk1P6+bPgE1gtZO/wp S/bg== X-Gm-Message-State: ALoCoQlzo/a6Z+S5Fa6oM8mWjHctyRvPA+pCQKL0CfKrP/LLxX7hUyiKQ9hMtmioDjT4tCIpkwX4 MIME-Version: 1.0 X-Received: by 10.112.129.228 with SMTP id nz4mr26700271lbb.9.1410170729833; Mon, 08 Sep 2014 03:05:29 -0700 (PDT) Sender: stedolan@stedolan.net Received: by 10.114.11.65 with HTTP; Mon, 8 Sep 2014 03:05:29 -0700 (PDT) X-Originating-IP: [131.111.184.8] In-Reply-To: References: Date: Mon, 8 Sep 2014 11:05:29 +0100 X-Google-Sender-Auth: En4owcvCV2_YIJI8OaVqUGAtZN8 Message-ID: From: Stephen Dolan To: Jiten Pathy Cc: caml-list@inria.fr Content-Type: text/plain; charset=UTF-8 Subject: Re: [Caml-list] Multicore runtime 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