ThreadPool.UnsafeQueueUserWorkItem(WaitCallback, Object) Method
Definition
Important
Some information relates to prerelease product that may be substantially modified before it’s released. Microsoft makes no warranties, express or implied, with respect to the information provided here.
Queues the specified delegate to the thread pool, but does not propagate the calling stack to the worker thread.
public:
static bool UnsafeQueueUserWorkItem(System::Threading::WaitCallback ^ callBack, System::Object ^ state);
public static bool UnsafeQueueUserWorkItem(System.Threading.WaitCallback callBack, object state);
[System.Security.SecurityCritical]
public static bool UnsafeQueueUserWorkItem(System.Threading.WaitCallback callBack, object state);
static member UnsafeQueueUserWorkItem : System.Threading.WaitCallback * obj -> bool
[<System.Security.SecurityCritical>]
static member UnsafeQueueUserWorkItem : System.Threading.WaitCallback * obj -> bool
Public Shared Function UnsafeQueueUserWorkItem (callBack As WaitCallback, state As Object) As Boolean
Parameters
- callBack
- WaitCallback
A WaitCallback that represents the delegate to invoke when a thread in the thread pool picks up the work item.
- state
- Object
The object that is passed to the delegate when serviced from the thread pool.
Returns
true if the method succeeds; OutOfMemoryException is thrown if the work item could not be queued.
- Attributes
Exceptions
The caller does not have the required permission.
An out-of-memory condition was encountered.
The work item could not be queued.
callBack is null.
Remarks
Unlike the QueueUserWorkItem method, UnsafeQueueUserWorkItem does not propagate the calling stack to the worker thread. This allows code to lose the calling stack and thereby to elevate its security privileges.
Caution
Using UnsafeQueueUserWorkItem could inadvertently open up a security hole. Code access security bases its permission checks on the permissions of all the callers on the stack. When work is queued on a thread pool thread using UnsafeQueueUserWorkItem, the stack of the thread pool thread will not have the context of the actual callers. Malicious code might be able exploit this to avoid permission checks.