> In local.glasgow-haskell-users, you wrote:
> > That makes isEmptyChan essentially useless. Either it should be
> > removed, or the implementation of Chan needs to be
> elaborated to support
> > isEmptyChan.
>
> I have a new implementation here which should track the
> number of elements
> in a channel, taking also into account unGetChan & dupChan.
> It seems to
> work, but lacks thorough testing. In any case, as it bloats
> the data structure
>
> data Chan a
> = Chan (MVar ([MVar Integer],Stream a))
> (MVar ([MVar Integer],Stream a))
> (MVar Integer)
>
> type Stream a = MVar ([MVar Integer],ChItem a)
>
> it should probably be something like Control.Concurrent.CountChan.
>
> http://www.foldr.org/~stolz/Chan2.hs
Could you explain how this works? writeChan doesn't update the count -
it should, right? But if it does, won't there be race conditions when
read & write happen at the same time?
> [although I consider
> mapM_ (uncurry putMVar) (zip counts (map (+1) vs))
> rather neat :)]
Not as neat as
zipWithM_ putMVar counts (map (+1) vs)
:-p
Cheers,
Simon
_______________________________________________
Glasgow-haskell-users mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
