Making GHC’s I/O manager more scalable

Posted in Uncategorized
13 comments on “Making GHC’s I/O manager more scalable
  1. Andrey Popp says:

    Hi, first of all — thanks for your work on thit ticket. This is my the most awaited feature I am missing in GHC.

    Why do you consider using libev over raw calls to kqueue/epoll? As an another option, there is pure Haskell Event library by Johan Tibell.

  2. Johan Tibell says:

    If we had a common benchmark I could try to drop the event library in GHC base and see how it performs. It already supports select, epoll, and kqueue and has a very similar interface to the EventManager in your patch.

  3. Andrey Popp says:

    Johan, I’d like to see your event library in base. Maybe, we should move discussion to GHC trac?

  4. Johan, do you have a darcs or git repo for your event library handy?

    I’ll write a benchmark some time in the next few days. It’s not a very hard job: simply open some number of connections between a client and a server, and then send a byte over a random socket every so often.

    The tricky part is in accounting where the time spent goes. We might want to use the new event logging mechanism in 6.12 and ThreadScope for that.

  5. Kazu Yamamoto says:

    First of all, thank you for your work. I have been waiting for this kind work for a long time.

    I’m implementing a Web server
    with GHC. To get over the select() limitation, I wrote a C10K server library which use the *prefork* technique. That is, N processces are preforked, and a process limits acceptable connection to M. So, N * M connections can be handled.

    I would contribute the benchmark stuff since my team already
    know curl-loader and jMeter well. Please tell me what you want to measure…

    Keep in touch.

  6. Johan Tibell says:


    It’s at

    We could use the libev benchmark for inspirations. It opens a number of pipes and sends a byte over each like you said.

  7. Brian Bloniarz says:

    Really interesting and promising stuff.

    FYI: I investigated libev for an application, had a pretty good impression overall — well thought out and functional. It had a major drawback for us, though: the main loop supports various timers, and to implement that it calls gettimeofday() twice for each call to poll(). This occurs regardless of whether you’ve registered any timers or not.

    We decided that was too much overhead for our app (lots of small UDP reads). It also didn’t help that libev uses a direct gettimeofday() syscall by default, instead of glibc’s faster vdso implementation (see EV_USE_CLOCK_SYSCALL).

  8. F*ckin’ amazing issues here. I’m very glad to peer your post. Thanks so much and i’m taking a look forward to touch you. Will you kindly drop me a e-mail?

  9. iqos sigara says:

    Bu kadar harika gönderilerin olduguna inanamıyorum. gerçekten teşekkürler. çok iyisiniz dostum

  10. iqos heets says:

    Bu konuda yeteri düzeyde içerik ürettiğinizi gördüm. ben sürekli sizi takip eden biri olarak başarılarınızın devamını dilerim.

  11. ıqos says:


    iqos iluma pmi şirketi tarafından üretilen yeni nesil tütün buharlaştırıcı cihazlardır. ıqos cihazlar heets sigara uyumlu tütün çubukları ile kullanılmaktadır.

    İç hava kalitesini olumsuz etkilemeyen ve sigara dumanının’dan daha az koku üreten nikotin içerikli sigarası iqos 3 duo cihazla beraber buharı dışarı verir.Heets sigarayı kullanmış olduğumuz sigaralardan ayıran belirgin özelliği, kullanılan sigaralarda bulunan ( zifir, nikotin, karbondioksit )zararlı bileşenlerin 3/1 sadece nikotin içermektedir. İqos cihazlar ile ısıtılarak buhar yoluyla’da sizlere sunulduğu için normal sigaraya nazaran %90 daha az zararlıdır. Bu sayede hem size hem de çevrenize daha sağlıklı zararsız bir yaşam sağlar. Bu cihazlar günlük hayatımızda kullanıma uygun bir şekilde tasarlanmış ve şık tasarımları ile dikkat çeken cihazlardır.

  12. iqos iluma says:

    Mükemmel içerik tesekkurler kalıtelı blog sayfası

  13. iqos fiyat says:

    bu deneme oldukça başarılı gibi görünüyor.

6 Pings/Trackbacks for "Making GHC’s I/O manager more scalable"
  1. […] couple of weeks, I have been working with Johan Tibbell on an event library to use for replacing GHC’s existing I/O manager. The work has been progressing rather nicely: I now have both the epoll and kqueue back ends […]

  2. […] Making GHC’s I/O manager more scalable – Dec 17, 2009 […]

  3. […] there is work to make the IO manager more scalable — now with a paper on the design :: […]

  4. […] there is work to make the IO manager more scalable now with a paper on the design :: […]

  5. […] there is work to make the IO manager more scalable now with a paper on the design :: […]

  6. […] tanto, hay trabajo para hacer que el administrador de E/S sea más escalable, ahora con un documento sobre el diseño :: […]

Leave a Reply

Your email address will not be published. Required fields are marked *