From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id B63EF20A1E; Sat, 8 Dec 2018 17:20:37 +0000 (UTC) Date: Sat, 8 Dec 2018 17:20:37 +0000 From: Eric Wong To: "Lin Jen-Shin (godfat)" Cc: yahns-public@yhbt.net Subject: Re: [PATCH 1/2] Add QueueQuitter#closed? to queue_quitter_pipe.rb Message-ID: <20181208172037.6ccjk4jv3mb5x7il@dcvr> References: <20181208083019.4374-1-godfat@godfat.org> <20181208113616.juj2wng2eyelheed@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: "Lin Jen-Shin (godfat)" wrote: > On Sat, Dec 8, 2018 at 7:36 PM Eric Wong wrote: > > Thanks for both patches, applied to https://yhbt.net/yahns.git > > > > Anything else? Might tag a release, soon. > > No, so far it's working great locally for me, thank you! I am very > happy I can use yahns on Mac OSX now. So much easier to develop (and > promote to the other developers) Great, good to know. > Previously I have no idea why but sleepy_penguin has some compile > error which I can't figure out how to fix, and it really looks like > it's Ruby's bug. They probably fixed it on one of the recent Ruby > patch releases, and it works fine after the `closed?` patch. Is it this? https://bogomips.org/sleepy-penguin/20170415002501.19627-1-e@80x24.org/ Totally forgot about it, and I've even been using a FreeBSD a bunch, just not with 3rd-party gems. > It's unrelated but I am happy that yahns quits gracefully upon > receiving SIGINT, while unicorn quits forcefully. I thought I might > try to add something to the application to eliminate the difference, > but since I could just run yahns everywhere I don't have to now. Yes, I figured since the APIs are different (and I consider signal handlers part of an API) it's safe to play around with the defaults a little as long as it's non-destructive on errors. One downside with graceful-shutdown-by-default and the generous timeouts is I've had it cause rebooting a machine to take way longer than expected, which increased downtime :x > > Getting rid of kgio is going to be a bit of work... > > This really comes with a long way, and on the bright side, we're > moving forward :) Thank you for all the works! You're welcome. Btw, which versions of Ruby are you using? I'm pretty sure Ruby 2.0 support compatibility is no longer necessary, these days; so we can rely on "exception: false" in more places and slowly remove kgio dependencies. Fwiw, I'm prepping a fork of yahns to demo Thread::Light , too working on lib/yahns/proxy_pass.rb was too much of a nightmare; so I wanted to keep all the Ruby parts synchronous.