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=-2.9 required=3.0 tests=AWL,BAYES_00,
	HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_MED,SPF_PASS,T_RP_MATCHES_RCVD
	shortcircuit=no autolearn=no 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 877391F404
	for <normalperson@yhbt.net>; Mon, 29 Jan 2018 22:23:47 +0000 (UTC)
Received: from neon.ruby-lang.org (localhost [IPv6:::1])
	by neon.ruby-lang.org (Postfix) with ESMTP id 817781208F8;
	Tue, 30 Jan 2018 07:23:45 +0900 (JST)
Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64])
 by neon.ruby-lang.org (Postfix) with ESMTPS id 1DA831208EF
 for <ruby-core@ruby-lang.org>; Tue, 30 Jan 2018 07:23:40 +0900 (JST)
Received: from localhost (dcvr.yhbt.net [127.0.0.1])
 by dcvr.yhbt.net (Postfix) with ESMTP id 122101F404;
 Mon, 29 Jan 2018 22:23:37 +0000 (UTC)
Date: Mon, 29 Jan 2018 22:23:36 +0000
From: Eric Wong <normalperson@yhbt.net>
To: ruby-core@ruby-lang.org
Message-ID: <20180129222336.GA12924@starla>
References: <redmine.issue-13618.20170601001407@ruby-lang.org>
 <redmine.journal-69988.20180129212836.54722b3ce368b865@ruby-lang.org>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <redmine.journal-69988.20180129212836.54722b3ce368b865@ruby-lang.org>
X-ML-Name: ruby-core
X-Mail-Count: 85237
Subject: [ruby-core:85237] 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>

sam.saffron@gmail.com wrote:
> I like ThreadTask a lot since these things are coupled with
> threads. I think ThreadJob works as well. 

Maybe we can call it what it is:  Thread::Green

I suspect using top-level namespace is unnecessary and may
introduce conflicts.

> API wise we can even avoid this altogether with
> 
> Thread.current << lambda {  }
> 
> So we don't even need to think about async vs add_task vs add_job

I like that.

One question, is how will Thread#[]/#[]= be handled inside
the lambda?

> > Yes, it's a requirement at the moment since migrating Fibers
> > across Threads is not possible.
>
> I would like to hear a bit more about this, could there be an
> "expensive" thread transfer operator added perhaps that only
> moves when the fiber once suspended? 

One problem is the act of suspending it (Fiber.yield)
will need to change.  Maybe it could default to fast suspend,
and the migrate operation would:

	1. set a flag to indicate migration in progress
	2. resume
	3. see + clear migration flag
	4. suspend again immediately, but slowly for migration

But it's a totally orthogonal issue to auto-fiber

/me goes back to working on non-Ruby stuff...