Wrap an AutoResetEvent object in a restricted WaitHandle?
I've built a library that launches a thread to do it's thing and returns a WaitHandle to the caller.
Looking at a bug report, I suspect the code that's calling my library is taking the returned object and casting it to an AutoResetE开发者_Go百科vent (which it is) and raising the flag itself. It's not meant to do that.
Is there a way I can wrap the AutoResetEvent object with one that can still be WaitOne'd and WaitAny'd, but can only be raised by my code?
Thanks.
You can create a new class derived from EventWaitHandle
and override Set
and Reset
so they do nothing, or throw an exception. Actually, you would have to create new
implementations, since Set
and Reset
aren't virtual. Of course, you'd have to create your own, other-named methods. Like MyInternalSet
and MyInternalReset
. Possible, but I wouldn't recommend doing it.
Instead I would document that the client should not set or reset the event, because doing so will cause unpredictable behavior.
You could create a WaitHandle
-derived class that holds your AutoResetEvent
as an internal
property. Client code then wouldn't be able to access it. Something like:
public class MyWaitHandle: WaitHandle
{
internal AutoResetEvent InternalEvent { get; private set; }
internal MyWaitHandle(AutoResetEvent event)
{
InternalEvent = event;
}
public override bool WaitOne(int32 timeout)
{
return InternalEvent.WaitOne();
}
}
You'll have to override the protected Dispose(Boolean)
method, so that it will dispose the internal handle, and you'll want the other WaitOne
overloads, as well. You can then create internal
implementations of Set
and Reset
, or just have your code call InternalHandle.Set
.
I still think the best course of action is to tell the client not to do that. But if you must prevent it, the above should work.
精彩评论