[Haskell-cafe] threadWaitRead and threadWaitWrite on multiple fds

Mathijs Kwik bluescreen303 at gmail.com
Mon Dec 13 09:06:43 CET 2010

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 <bluescreen303 at gmail.com> 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 <mmitar at gmail.com> wrote:
>> Hi!
>> On Mon, Dec 13, 2010 at 2:14 AM, Antoine Latter <aslatter at 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

More information about the Haskell-Cafe mailing list