UnsafeQueueUserWorkItem and what exactly does "does not propagate the calling stack" mean?

It is an implementation detail of CAS, Code Access Security. Which can check whether a thread has sufficient rights to perform an operation. It only matters if code runs in a restricted security environment, not running with full trust or in a sandbox.

The plumbing that makes this work is complicated and I can only approximate the way it works. The ExecutionContext class is key, it determines the security context in which code runs. Things get difficult when a thread that runs with restricted rights starts another thread. Clearly that other thread needs to run with the same kind of restrictions as the original thread. CAS depends on the being able to perform stack walks to discover restrictions. That's difficult on another thread, it has its own stack.

The ExecutionContext.Capture() method performs an essential role here. It makes a copy of the context of the calling thread, including making a stack walk to create a "compressed" stack of the security attributes discovered. The new thread then runs with that captured context.

ThreadPool.UnsafeQueueUserWorkItem() skips the Capture() call. The threadpool thread will run with the default execution context.

This is an optimization, Capture() is not a cheap method. It matters in the kind of program that depends on TP threads to get stuff done in a hurry. A web server jumps to mind. Also the kind of code that uses the method, you see it used in internal methods in the System.Net namespace for example.

Clearly it is unsafe, it doesn't run with the CAS restrictions of the originating thread.


Comments

  1. Jared

    • 2019/12/5

    What does that exactly mean to propagate a stack? Copy it over before the work starts? Why would another thread need the stack of the calling 

  2. Dario

    • 2017/12/3

    In the MSDN description about UnsafeQueueUserWorkItem there is a big warning that the function may be an security hole and that it "does not propagate the calling stack". The only link is to QueueUserWorkItem which - from the name - seems to be the "safe counterpart"? but does not mention anything about calling stacks either.

  3. Louie

    • 2016/2/5

    Definition; Overloads; UnsafeQueueUserWorkItem(IThreadPoolWorkItem, Boolean) but does not propagate the calling stack to the worker thread.

  4. Moretti

    • 2018/6/23

    In the MSDN description about UnsafeQueueUserWorkItem there is a big warning that the function may be an security hole and that it "does not propagate the calling stack". The only link is to QueueUserWorkItem which - from the name - seems to be the "safe counterpart"? but does not mention anything about calling stacks either.

  5. Cash

    • 2020/8/20

    der Thread Pool wird dies nicht tun.It is the responsibility of that work item to propagate ExecutionContext if it's needed; the thread pool will not do so.

  6. Pagano

    • 2021/2/3

    ThreadPool.UnsafeQueueUserWorkItem přeskočí výzvu snímání (). Threadpool vlákno poběží s výchozí kontextu provádění. Jedná se o optimalizaci Capture není levná metoda. Záleží na tom, v druhu programu, který závisí na TP závity dostat věci udělat ve spěchu. Webový server vyskočí na mysl.

  7. Jamal

    • 2016/11/27

    ProcessRequest is called from a threadpool thread. It starts the asynchronous Yet, it does not fit what we observed on our own servers.

  8. Alejandro

    • 2016/1/19

    Στο MSDN περιγραφή για UnsafeQueueUserWorkItem υπάρχει μια μεγάλη προειδοποίηση ότι η λειτουργία μπορεί να είναι μια τρύπα ασφάλειας και ότι « δεν διαδίδουν την κλήση στοίβας ».

  9. Bjorn

    • 2017/7/8

    The unsafe versions are called. * that because they do not propagate the calling stack onto the. * worker thread. This allows code to lose the calling stack 

  10. Reyes

    • 2020/2/22

    ThreadPool.UnsafeQueueUserWorkItem salta la chiamata Capture (). Il filo threadpool verrà eseguito con il contesto di esecuzione predefinito. Si tratta di un'ottimizzazione, Capture non è un metodo a basso costo. È importante nel tipo di programma che dipende discussioni TP per ottenere roba fatta in fretta. Un server web salta in mente.

  11. Preston

    • 2016/4/30

    By multiplexing the calls over this small thread pool, we can free up a lot of other threads more doing non-IO related work. This is exactly 

  12. Aayan

    • 2017/3/11

    23 UnsafeQueueUserWorkItem and what exactly does "does not propagate the calling stack" mean? 12 Enumerating over lambdas does not bind the scope correctly? 11 Is there any way I can integrate the MS Office Smooth Typing in a C# application?

  13. Bentley

    • 2019/11/16

    Most of books says that we should not overplay with performance, UnsafeQueueUserWorkItem is faster than QueueUserWorkItem.

  14. Nasir

    • 2020/4/9

    Unlike the QueueUserWorkItem method, UNSAFEQUEUSERWORKITEM does not propagate the call stack to the secondary thread. This allows the code to lose the call 

Comments are closed.

Recent Posts