2015-10-07 18:30 GMT+02:00 David Turner <dct25-56...@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 _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
