Roel van Dijk wrote:
2010/2/16 Neil Brown <[email protected]>:
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.
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
