Yep, that's like the workaround I'm using right now. I create an empty mvar, fire up 2 threads that will wait for an fd and tryPutMVar afterwards. My original thread justs gets the MVar to wait for any of the 2 fd-waiting-threads to complete. But however light threads may be, I still think this might give some overhead, and it's almost the same trick that System/Event/Thread is using internally, although in that case, the putMVar is performed by the event manager thread. As far as I can tell, the behavior isn't hard-coded in the RTS (no need to change that), but applications that use base will tell it to use the mvar-trick as callback. That's why I was hoping to be able to just tell it to use a different callback.
But indeed it's a solution for now. I'll just post a feature-request for GHC. Thanks On Mon, Dec 13, 2010 at 3:19 AM, Mitar <mmi...@gmail.com> wrote: > Hi! > > On Mon, Dec 13, 2010 at 2:14 AM, Antoine Latter <aslat...@gmail.com> wrote: >> Can you do it with forkIO? That is, have two light-weight threads, >> each waiting on a different fd, which perform the same action when one >> of them wakes up. > > Or you could wait for each fd in its own thread (those are really > light-weight threads) and once some is triggered you spawn another > thread which deals with the event, while the original thread goes back > into the waiting. Or you can also send data over Chan to another > thread which then processes the even (if you need to serialize > processing). > > > Mitar > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe