From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS33070 50.56.128.0/17 X-Spam-Status: No, score=0.7 required=3.0 tests=AWL,MSGID_FROM_MTA_HEADER, RDNS_NONE shortcircuit=no autolearn=no version=3.3.2 Path: news.gmane.org!not-for-mail From: "Lin Jen-Shin (godfat)" Newsgroups: gmane.comp.lang.ruby.rainbows.general Subject: Re: EventMachine with thread pool and thread spawn Date: Fri, 6 Sep 2013 03:59:11 +0800 Message-ID: References: <20130823225114.GA5691@dcvr.yhbt.net> <20130825215701.GA31966@dcvr.yhbt.net> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1378411187 1310 80.91.229.3 (5 Sep 2013 19:59:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Sep 2013 19:59:47 +0000 (UTC) To: "Rainbows! list" Original-X-From: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Thu Sep 05 21:59:51 2013 Return-path: Envelope-to: gclrrg-rainbows-talk@m.gmane.org X-Original-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Delivered-To: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=godfat.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=BPFtbPqIvej0RmrjRK/5Yx0DgxKjz9G0qXIduwZ5NoI=; b=KPDB13BHNHbSrQcWmEdfnKljilwHIj+WkCbN6CZBN9VQVLaCNVG0sMIkkuxxcUY4rD s/4XS/hWDsluDO1nUZ18M+uEQPJxEjokRiKpwAxiSrBuF17aiZuQTZeau5ZMvWTTgG2U Q6mj/Y/OUZHlVmkWR41o4BDndWcW+7uOj3Yig= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=BPFtbPqIvej0RmrjRK/5Yx0DgxKjz9G0qXIduwZ5NoI=; b=BE6SeOcYU9NEBcsZNRGhj6CFVoXnXQIRwdpUswGwsauilwOVUaCUAHBcEAy/gXfDf7 LoBCaZpFQ85V9lrm+9ntiv8BaFrdnijovZmyrMTak2719PC9pD1jpMi4FobWuNmP+qKW mwySRHcbRTK3vaxdBSgUrts2CgYFD4RGSFxTqrNmTnPpqsD4SnzG2OOIcFExTe780wnN 5xr3BOS7PvZfREg32njbKIqu4vLRaiCfrsHcTqvyRyFEKSR3eelv8x9yu4eP7IvN16cE CTJNDc8juL18p/gTAPLmGI1ydBLKH+oRa8BQH7bDcS73JOrSeb6nlbS+xnZpZJ4xtyyj TGmg== X-Gm-Message-State: ALoCoQl+Agcgml+OxoYpKfhQ3I+y2vn0ktPXgql8j8MhY5S7hdra2+U5mmjX+lCaA2DjkEqsfulC X-Received: by 10.14.199.3 with SMTP id w3mr16070887een.33.1378411181700; Thu, 05 Sep 2013 12:59:41 -0700 (PDT) In-Reply-To: <20130825215701.GA31966-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org> X-BeenThere: rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org Errors-To: rainbows-talk-bounces-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org X-Broken-Reverse-DNS: no host name found for IP address 50.56.192.79 Xref: news.gmane.org gmane.comp.lang.ruby.rainbows.general:533 Archived-At: Received: from [50.56.192.79] (helo=rubyforge.org) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VHfiY-0008UH-Dw for gclrrg-rainbows-talk@m.gmane.org; Thu, 05 Sep 2013 21:59:50 +0200 Received: from localhost.localdomain (localhost [127.0.0.1]) by rubyforge.org (Postfix) with ESMTP id 6263A2E17C; Thu, 5 Sep 2013 19:59:50 +0000 (UTC) Received: from mail-ea0-f178.google.com (mail-ea0-f178.google.com [209.85.215.178]) by rubyforge.org (Postfix) with ESMTP id A49472E145 for ; Thu, 5 Sep 2013 19:59:43 +0000 (UTC) Received: by mail-ea0-f178.google.com with SMTP id a15so1149478eae.9 for ; Thu, 05 Sep 2013 12:59:41 -0700 (PDT) Received: by 10.223.172.69 with HTTP; Thu, 5 Sep 2013 12:59:11 -0700 (PDT) On Mon, Aug 26, 2013 at 5:57 AM, Eric Wong wrote: > "Lin Jen-Shin (godfat)" wrote: [...] > kqueue is a queue, it's in the name. I haven't looked too hard at the > internal details, but the name says much about it :) > > I've studied epoll internals a bit and know that epoll is also a queue, > it's just not in the name. > > Oneshot behavior basically makes epoll/kqueue behave like a traditional > queue; once you pull a file/socket off the queue, it won't magically > reappear unless you ask epoll/kqueue to watch for it again. > > This is significant for multithreaded servers, because it allows the > kernel to handle synchronization (just like accept()). > > Level/edge-triggered epoll/kqueue is kind of like a tracklist in a music > player with repeat=on + random=on. It's fine if you're playing one > track-a-time (like a single-threaded HTTP server), but if you try to > play multiple tracks in different threads, you could end up playing the > _same_ track in two or more threads. > > A multi-threaded HTTP server must implement its own synchronization > on top of ET/LT epoll/kqueue to prevent serving the same client > from multiple threads. I searched and read a bit. I am not sure if I understand correctly, but I have a feeling that both LT and ET epoll are not designed to be used in a multithreaded server (i.e. handle I/O in epoll and dispatch tasks to threaded handlers), or say it would be quite hard to get it right. That is, oneshot would be the way to go in this scenario? I also heard that libev is merely a thin wrapper around epoll... >> I wonder if I should just go with XEpollThreadPool then? My concern >> is that as Heroku does not buffer the entire request and response, >> we need something which would do this for us. Not sure if XEpollThreadPool >> would be sufficient? > > Probably using XEpollThread* is a good choice, but neither buffer (but > you get more I/O concurrency anyways, so maybe it's not so bad) After benching mark against Heroku, I feel it does have some kind of buffers. It's hard to tell though........ but yeah, maybe we don't really need full buffering at application server level. > Plain XEpoll does do full buffering, and you can probably add a > TryDefer-like middleware on top of that, even... Could you please explain to me why there's difference? Is it because it might not make too much sense to buffer in XEpollThread*, or implementation-wise, it's easier to do it this way? > Anyways, it's still infuriating to me that Heroku cannot do full > buffering and still claims to "support" unicorn. They do provide a way to customize the deployment, so that we could build an Nginx while deploying and run it for each unicorn process though. They do not officially support this, but it could work... things might break easily if they changed something though. The reason why they don't fully buffer is because of latency concern as far as I know. But I feel in most of the web apps, we don't really do realtime stuffs. And the most frustrating thing to me is that my co-workers don't really trust me. They still prefer unicorn because Heroku recommends it officially even when I showed benchmarks and some people at Heroku did admit it could be an issue. I am so tired of this. > I can't officially support non-Free systems, but I can accept > non-intrusive patches. I'm not nearly as experienced with kqueue, > so maybe you really found a bug in my kqueue API. > > Anyways, I've considered unifying a X{Epoll,Kqueue}Thread* interface, > which is why I added kqueue support to sleepy_penguin before I forgot > about it :x Thanks for reading my patch. Hope one day I could jump to Linux for my daily life as well :) I'll look into how clogger does the fallback. I guess the idea is similar to duck "platforming" :P This would also have the advantage that maybe one day the platform would catch up and provide the same functions... > I didn't get it on the list and can't find it on the archives, either. > http://librelist.com/browser/sleepy.penguin/ > Are you sure it went out? Feel free to Bcc me or send it here. > > (Librelist doesn't like plain Cc :<) > > It could be a librelist problem, too, but I just sent out a message > considering a move away from librelist and it went through fine: > http://mid.gmane.org/20130825212946.GA32430-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org What's happening was that I sent it to librelist, and received an email from librelist for confirming if I am subscribing it. I replied the confirmation, wondering if my previous mail would show up or not? I was worried about sending it twice, thus didn't send again. It seems after the confirmation everything works normally. Not sure if librelist is a good choice, but at least it seems working for me now. _______________________________________________ Rainbows! mailing list - rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org http://rubyforge.org/mailman/listinfo/rainbows-talk Do not quote signatures (like this one) or top post when replying