From mboxrd@z Thu Jan 1 00:00:00 1970 From: Casey Bodley Subject: Re: seastar and 'tame reactor' Date: Tue, 13 Feb 2018 10:58:36 -0500 Message-ID: References: <5b32056c-c6f7-a1c4-d07a-ae04557b59cf@redhat.com> <9e6bc174-c6b3-a37e-abd5-b96d572d1d1b@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-qt0-f181.google.com ([209.85.216.181]:33863 "EHLO mail-qt0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933730AbeBMP6j (ORCPT ); Tue, 13 Feb 2018 10:58:39 -0500 Received: by mail-qt0-f181.google.com with SMTP id d14so4146111qtg.1 for ; Tue, 13 Feb 2018 07:58:38 -0800 (PST) In-Reply-To: Content-Language: en-US Sender: ceph-devel-owner@vger.kernel.org List-ID: To: kefu chai , Matt Benjamin Cc: Gregory Farnum , Josh Durgin , Adam Emerson , ceph-devel On 02/13/2018 08:35 AM, kefu chai wrote: > On Mon, Feb 12, 2018 at 11:55 PM, Matt Benjamin wrote: >> How does tame reactor induce more OSD sessions (@greg); @kefu, in't >> the hybrid model another way of saying, tame reactor? The intuition > i just realized that it is =) > >> I've had to this point is that the interfacing here is essentially >> similar to making seastar interact with anything else, including >> frameworks (disks, memory devices) that it absolutely wants to and >> must. >> > Sorry, I'm probably confusing things here by reusing the 'tame reactor' term that Adam coined. The original idea was to allow external threads to construct a seastar reactor, and call some new function that does a single polling/event loop before returning control to that thread. The word 'tame' meant that it wouldn't steal control from your thread forever like reactor::run() does. This 'external queue' idea is a different and less ambitious way to integrate with non-seastar threads that got some upstream buy-in from Avi.