Handling multiple fds with GHC

[Markus Ongyerth]

2015-10-07 18:30 GMT+02:00 David Turner <dct25-561bs at mythic-beasts.com>:
> Hi,
>
> Why the non-threaded runtime, out of interest?

Mostly because i am used to the poll/select method I mentioned and that
one works without any threading.
I don't really mind using the threaded runtime though, it's more habit.

> Threads forked with forkIO are pretty lightweight, and although things look
> like blocking calls from the Haskell point of view, as I understand it under
> the hood it's all done with events of one form or another. Thus even with
> the non-threaded runtime you will see forkIO-threads behaving as if they're
> running concurrently. In particular, you have two threads blocked trying to
> read from two different Handles and each will be awoken just when there's
> data to read, and the rest of the runtime will carry on even while they're
> blocked. Try it!

Yeah, I know and I tried that.
As far as I can see, that's actually why things break with GHC.Event.
The Event system tries to register the Fd while it was registered by me
and encounters an EEXIST from epoll.

> If you're dealing with FDs that you've acquired from elsewhere, the function
> unix:System.Posix.IO.ByteString.fdToHandle can be used to import them and
> then they work like normal Handles in terms of blocking operations etc.
>
> Whenever I've had to deal with waking up for one of a number of reasons (not
> all of which are FDs) I've found the simplicity of STM is hard to beat.
> Something like:
>
> atomically ((Left <$> waitForFirstThing) <|> (Right <$> waitForSecondThing))

Looks like I should look up STM. Does this scale easily?
I don't really need huge amounts, but I don't have any knowledge about the
number of Fds I will have.

> where waitForFirstThing and waitForSecondThing are blocked waiting for
> something interesting to occur in a TVar that they're watching. It's so
> simple that I reckon it's worth doing it like that and only trying something
> more complicated if it turns out from experimentation that this has too much
> overhead for you - "make it right" precedes "make it fast".
>
> Hope that helps,
>
> David

Thanks for the help,

Ongy