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

[Jonathan Pryor]

On Tue, 2004-03-16 at 04:37, Mr. Deepak P N wrote:
<snip/>
> 	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.

Simple.  The fact that a class is abstract has NO bearing on whether it
can have constructors.  An abstract class just cannot be directly
instantiated, but concrete subclasses can be, and they will need to
invoke the abstract classes constructor.

All classes have at least one constructor, even if it's the
compiler-generated default constructor, so all derived class
constructors will *always* invoke their base class constructor,
regardless of the abstract status of the base class.

I will admit that it doesn't make sense to have a public constructor on
an abstract class, which is why abstract class constructors are
typically protected, to further emphasize that the class must be derived
from.  It's still *valid* to have public constructors on abstract
classes.

> 	Even the MSDN documentation seems to mislead us by saying that
> WaitHadle() constructor Initializes a new instance of the WaitHandle
> class.

They're not misleading you.  WaitHandle has a constructor.

The WaitHandle constructor would be responsible for creating the
underlying (OS-native) semaphore/critical-section/lock.  Sub-classes
would override the various virtual/abstract functions (Close(),
WaitOne(), etc.), to change behavior as they see fit, but base their
behavior on the lock OS-lock held by the WaitHandle class.

The WaitHandle finalizer would be responsible for freeing the unmanaged
resources allocated in the constructor.  This keeps things sane, as all
resource acquisition and release is done in the same class.

 - Jon