[Haskell-cafe] Need comments on a libusb asynchronous select/poll loop

[John Obbele]

On Tue, Apr 19, 2011 at 08:52:44AM -0500, Antoine Latter wrote:
> Maybe I'm misunderstanding something, but why why I want to use epoll
> directly instead of just using forkIO plus threadWaitRead and
> threadWaitWrite?
> 
> http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html#v:threadWaitRead
> 
> As a developer, the concurrency model offered by the
> Control.Concurrency module has always been friendly to me.

So instead of blindly following the C documentation on how to
poll libusb, I should simply spawn a forkIO on each file
descriptors and wait for the threadWait{Write,Read} to do their
magic ?

Something like:

readAsyncIO = do $
    zipfds <- getLibusbFileDescriptorsStruct
    mapM_ (forkIO . monitor) zipfds

 where monitor args@(readOrWrite, fd) = do
        if isRead readOrWrite
            then threadWaitRead fd
            else threadWaitWrite fd
        libusbHandleAllPendingsEvents
        monitor args -- loop recursion

Of course, I would have to use MVars or libusb lock API to verify
that no two Haskell threads were trying to flush the events pool
at the same time.

hum ... wait, we don't use locks in Haskell, we use STM, don't we ?

> Maybe there was something in the other thread I missed.
I'm always lost in these long discussions about the overall
merits of this one method or this another one.

A (real) example helps me better to grasp the notions.

/john