Re: [Mono-list] 3 TODOs in Threading namespace almost completed

[Jaroslaw Kowalski]

Looks like there's a regression in your code when compared to the current CVS.   In Timer.Runner.Dispose(bool) it is possible that you call wait.Set() on an already-disposed "wait" object which holds unmanaged resource.   Consider this scenario:   1. You create new Runner() 2. Runner() constructor creates a new ManualResetEvent() 3. ...some time passes... 4. Both Runner and ManualResetEvent become garbage so they are added to the finalization queue 5. ManualResetEvent gets finalized first 6. You call "wait.Set()" on it when finalizing Runner which leads to some strange results.   This causes the possible deadlocks when unloading appdomains and was reported as a bug and fixed here:   http://bugzilla.ximian.com/show_bug.cgi?id=54980   BTW. Why is that Thread.Sleep(100) needed there ? This looks like a huge hack.   Jarek ----- Original Message ----- From: Mr. Deepak P N To: [EMAIL PROTECTED] ; [EMAIL PROTECTED] ; [EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 10:37 AM Subject: [Mono-list] 3 TODOs in Threading namespace almost completed Hi,           I have implemented the Change() method[ false return value ] and the Dispose() method, which was incomplete. Please inform me whether this is fine or it needs any other modification. [Although this gave raise to another todo, which I am working on].      Since the WaitHandle class is an abstract class, we obviously cannot instantiate an instance of its type.  So, how can there be an implementation of a constructor.      Even the MSDN documentation seems to mislead us by saying that WaitHadle() constructor �Initializes a new instance of the WaitHandle class�.      I think the TODO does not exist. I am interested in completing all the TODOs in �System.Threading� namespace. P.S: Timer.cs attached Best Regards, Deepak.