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 <bluescreen...@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 <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
