Re: [Haskell-cafe] threadWaitRead and threadWaitWrite on multiple fds

Just to reply to myself once again, System.Event (which isn't hidden) re-exports (un)registerFd and other functions I need for this. So I can implement all this myself. The only thing I can't do is ask the RTS's eventmanager to watch the fds for me, but I can just create my own ("new" constructor is exposed as well) to keep all fd-watching in 1 thread. So it seems just enough functionality is exposed to do what I'm after. Those GHC devs must be clever guys :) On Mon, Dec 13, 2010 at 8:24 AM, Mathijs Kwik wrote:

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 wrote:

...

Hi!

On Mon, Dec 13, 2010 at 2:14 AM, Antoine Latter 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