2010/2/16 Neil Brown nc...@kent.ac.uk:
I had a look at the code for Event (both versions) and Lock (but not the
others just yet) and it seemed fine. If you do lots of calls to waitTimeout
before a set you will accumulate old locks in the list, but that won't cause
any error that I can see, so
Roel van Dijk wrote:
2010/2/16 Neil Brown nc...@kent.ac.uk:
I had a look at the code for Event (both versions) and Lock (but not the
others just yet) and it seemed fine. If you do lots of calls to waitTimeout
before a set you will accumulate old locks in the list, but that won't cause
any
2010/2/17 Neil Brown nc...@kent.ac.uk:
You don't need to do use ThreadId: MVar has an Eq instance, so you could
make your Lock type derive an Eq instance, and then you can just compare the
Locks to remove it after the timeout occurs (e.g. using delete to take it
out of the list; it should be
Hello,
We wrote a small library (1) which offers a few extra synchronization
primitives. These primitives are found in the standard libraries of
languages like Java and Python, but not in Haskell.
Before releasing concurrent-extra on hackage, we would like some
comments on its name, design,
Hi,
I had a look at the code for Event (both versions) and Lock (but not the
others just yet) and it seemed fine. If you do lots of calls to
waitTimeout before a set you will accumulate old locks in the list, but
that won't cause any error that I can see, so it would only be a problem
in
