
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 see, so it would only be a problem in pathological cases.
I think I can fix the garbage locks on waitTimeout by tupling each lock with the ThreadId of the thread that created it. When a timeout occurs I can then simply remove the unnecessary lock from the list. The extra overhead would be the construction of a tuple and acquiring a ThreadId each time you wait for an event.
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 head of the list anyway). In fact, you may as well make most of your types derive an Eq instance where possible, as this can be useful sometimes. Thanks, Neil.