2010/2/17 Neil Brown :
> 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 quite near the
Roel van Dijk wrote:
2010/2/16 Neil Brown :
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 s
2010/2/16 Neil Brown :
> 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 onl
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 pat
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, imple
