From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <ruby-core-bounces@ruby-lang.org>
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on dcvr.yhbt.net
X-Spam-Level: 
X-Spam-ASN: AS4713 221.184.0.0/13
X-Spam-Status: No, score=-3.5 required=3.0 tests=AWL,BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS
	shortcircuit=no autolearn=ham autolearn_force=no version=3.4.0
Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75])
	by dcvr.yhbt.net (Postfix) with ESMTP id 64453200B9
	for <normalperson@yhbt.net>; Sun,  6 May 2018 03:03:13 +0000 (UTC)
Received: from neon.ruby-lang.org (localhost [IPv6:::1])
	by neon.ruby-lang.org (Postfix) with ESMTP id CAC0B120992;
	Sun,  6 May 2018 12:03:10 +0900 (JST)
Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64])
 by neon.ruby-lang.org (Postfix) with ESMTPS id 8BA7D1208FF
 for <ruby-core@ruby-lang.org>; Sun,  6 May 2018 12:03:05 +0900 (JST)
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
 by dcvr.yhbt.net (Postfix) with ESMTP id 92A65200B9;
 Sun,  6 May 2018 03:03:01 +0000 (UTC)
Date: Sun, 6 May 2018 03:03:01 +0000
From: Eric Wong <normalperson@yhbt.net>
To: ruby-core@ruby-lang.org
Message-ID: <20180506030301.GA32080@dcvr>
References: <redmine.issue-13618.20170601001407@ruby-lang.org>
 <redmine.journal-71872.20180505130646.cd5df41838ef9e7f@ruby-lang.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <redmine.journal-71872.20180505130646.cd5df41838ef9e7f@ruby-lang.org>
X-ML-Name: ruby-core
X-Mail-Count: 86915
Subject: [ruby-core:86915] Re: [Ruby trunk Feature#13618] [PATCH] auto fiber
 schedule for rb_wait_for_single_fd and rb_waitpid
X-BeenThere: ruby-core@ruby-lang.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Ruby developers <ruby-core@ruby-lang.org>
List-Id: Ruby developers <ruby-core.ruby-lang.org>
List-Unsubscribe: <https://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>, 
 <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
List-Post: <mailto:ruby-core@ruby-lang.org>
List-Help: <mailto:ruby-core-request@ruby-lang.org?subject=help>
List-Subscribe: <https://lists.ruby-lang.org/cgi-bin/mailman/listinfo/ruby-core>, 
 <mailto:ruby-core-request@ruby-lang.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: ruby-core-bounces@ruby-lang.org
Sender: "ruby-core" <ruby-core-bounces@ruby-lang.org>

samuel@oriontransfer.net wrote:
> I've been thinking about these issues for the past few days, and one thing I found was this video https://www.youtube.com/watch?v=KXuZi9aeGTw#t=519 where they specifically talk about the latencies incurred by the threading model you propose. I just thought you might find it interesting.

Can you please summarize and perhaps link to code they talk about?

I don't have video now and I don't want it to become an expectation
that Ruby contributors be able to deal with video
(either through hardware, software or human physical limitation)


No rush, either, barely have any computer access for a bit.


Again, Mio (Glasgow Haskell Compiler) is most similar to what
I'm working on, here, and that scales to some ridiculous number
of cores:

http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf

I don't use a dedicated epoll thread like they do;
but I also know epoll_wait uses exclusive wakeup in Linux,
so there's no thundering herd when a single event arrives
when multiple threads are sleeping in epoll_wait.