aran.donohue:
That's very interesting. I only brought it up because I'm thinking about the
upcoming problems of real-time web application servers.
I'm sure many people have seen this blog post and Dons's replies:
http://www.codexon.com/posts/debunking-the-erlang-and-haskell-hype-for-servers
On Sun, May 2, 2010 at 8:45 PM, Aran Donohue aran.dono...@gmail.com wrote:
That's very interesting. I only brought it up because I'm thinking about
the upcoming problems of real-time web application servers.
I'm sure many people have seen this blog post and Dons's replies:
Re event library and merge into haskell base: has any thought gone into
the windows version of the library. Last I looked it was very unix
centric - the windows api is very different. I believe it will require
major rework to abstract the commonalities and deal efficiently with the
The event library has a pluggable interface, with multiple backends, and
is entirely portable as a result. You just swap in your 'select'
mechanism:
http://github.com/tibbe/event/blob/master/src/System/Event/EPoll.hsc
http://github.com/tibbe/event/blob/master/src/System/Event/Poll.hsc
As I said, it is very unix centric. The backend methods rely upon file
descriptors which in the windows world are specific to the C rts. It is
the backend that requires the abstraction from os specific
structures/handling.
The event library has a pluggable interface, with multiple backends,
On Mon, May 3, 2010 at 1:42 AM, John Lask jvl...@hotmail.com wrote:
Re event library and merge into haskell base: has any thought gone into the
windows version of the library. Last I looked it was very unix centric -
the windows api is very different. I believe it will require major rework to
Hi Aran,
On Fri, Apr 30, 2010 at 9:28 PM, Aran Donohue aran.dono...@gmail.comwrote:
Thanks for the excellent links, that's exactly what I wanted. It's
interesting that they've chosen not to base the new work on libevent.
The reason was mostly performance concerns due to libev(ent) using
Johan Tibell johan.tib...@gmail.com writes:
Hi Aran,
On Fri, Apr 30, 2010 at 9:28 PM, Aran Donohue aran.dono...@gmail.com wrote:
Thanks for the excellent links, that's exactly what I wanted. It's
interesting that they've chosen not to base the new work on
libevent.
The
In GHC, if a thread spawned by forkIO blocks on some network or
disk IO, is the threading system smart enough not to wake the thread
... disk IO, you say?
Most platforms support asynchronous I/O for what UNIX calls `slow'
devices - pipe, tty, Berkeley socket. Select, poll, kqueue, O_NDELAY,
Hello Aran,
Friday, April 30, 2010, 2:26:20 AM, you wrote:
In GHC, if a thread spawned by forkIO blocks on some network or
disk IO, is the threading system smart enough not to wake the thread
afaik, yes. it's controlled by special i/o thread that multiplexes all
i/o done via stdlibs. but ghc
bulat.ziganshin:
Hello Aran,
Friday, April 30, 2010, 2:26:20 AM, you wrote:
In GHC, if a thread spawned by forkIO blocks on some network or
disk IO, is the threading system smart enough not to wake the thread
afaik, yes. it's controlled by special i/o thread that multiplexes all
i/o
Thanks for the excellent links, that's exactly what I wanted. It's
interesting that they've chosen not to base the new work on libevent.
As an aside, I really don't think that the case study should be given any
more linkjuice as a response to GHC/Haskell IO concurrency questions. While
it's a
Hi Cafe,
In GHC, if a thread spawned by forkIO blocks on some network or disk IO, is
the threading system smart enough not to wake the thread until an IO event
occurs on its input/output? The Control.Concurrent documentation doesn't
specify, and the previous discussions I could find on this topic
13 matches
Mail list logo
