From: "Lin Jen-Shin (godfat)" <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org> To: "Rainbows! list" <rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org> Subject: Re: EventMachine with thread pool and thread spawn Date: Fri, 6 Sep 2013 03:59:11 +0800 Message-ID: <CAA2_N1utfNGSUcaNv9oLAHVzdO1MbC3wH0ar+wkfMHeCmPjkOQ@mail.gmail.com> (raw) In-Reply-To: <20130825215701.GA31966-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org> On Mon, Aug 26, 2013 at 5:57 AM, Eric Wong <normalperson-rMlxZR9MS24@public.gmane.org> wrote: > "Lin Jen-Shin (godfat)" <godfat-hOE/xeEBYYIdnm+yROfE0A@public.gmane.org> 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
next prev parent reply index Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2013-08-23 21:22 Lin Jen-Shin (godfat) [not found] ` <CAA2_N1uiz7Razb5J6wYCnD0w8sXrbCRp6LnLC+hTg2+Oipfrrw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-08-23 22:51 ` Eric Wong [not found] ` <20130823225114.GA5691-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org> 2013-08-25 12:34 ` Lin Jen-Shin (godfat) [not found] ` <CAA2_N1sqvUap-97EjpiKyLicXt3J5zeNSws3O4CAJ3VKUvgVcg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-08-25 21:57 ` Eric Wong [not found] ` <20130825215701.GA31966-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org> 2013-09-05 19:59 ` Lin Jen-Shin (godfat) [this message] [not found] ` <CAA2_N1utfNGSUcaNv9oLAHVzdO1MbC3wH0ar+wkfMHeCmPjkOQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2013-09-05 23:03 ` Eric Wong [not found] ` <20130905230305.GA5823-yBiyF41qdooeIZ0/mPfg9Q@public.gmane.org> 2013-09-26 17:59 ` Lin Jen-Shin (godfat) 2013-09-06 6:52 ` Eric Wong
Reply instructions: You may reply publically to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://bogomips.org/rainbows/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAA2_N1utfNGSUcaNv9oLAHVzdO1MbC3wH0ar+wkfMHeCmPjkOQ@mail.gmail.com \ --to=godfat-hoe/xeebyyidnm+yrofe0a@public.gmane.org \ --cc=rainbows-talk-GrnCvJ7WPxnNLxjTenLetw@public.gmane.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Rainbows! Rack HTTP server user/dev discussion Archives are clonable: git clone --mirror https://bogomips.org/rainbows-public git clone --mirror http://ou63pmih66umazou.onion/rainbows-public Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.lang.ruby.rainbows nntp://ou63pmih66umazou.onion/inbox.comp.lang.ruby.rainbows note: .onion URLs require Tor: https://www.torproject.org/ or Tor2web: https://www.tor2web.org/ AGPL code for this site: git clone https://public-inbox.org/ public-inbox