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
On Mon, Dec 13, 2010 at 9:06 AM, Mathijs Kwik bluescreen...@gmail.com wrote:
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
Hi all,
I read the paper about the new ghc7 event handling IO manager goodies.
This is all very exciting stuff. I didn't know GHC's RTS had these
smart async-IO facilities.
The paper pointed me at threadWaitRead/threadWaitWrite.
While very nice the way they are, I would also like to be able to
On Sun, Dec 12, 2010 at 6:37 PM, Mathijs Kwik bluescreen...@gmail.com wrote:
Hi all,
I read the paper about the new ghc7 event handling IO manager goodies.
This is all very exciting stuff. I didn't know GHC's RTS had these
smart async-IO facilities.
The paper pointed me at
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
On Mon, Dec 13, 2010 at 1:37 AM, Mathijs Kwik bluescreen...@gmail.com wrote:
Hi all,
I read the paper about the new ghc7 event handling IO manager goodies.
This is all very exciting stuff. I didn't know GHC's RTS had these
smart async-IO facilities.
The paper pointed me at
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
