J
John Puopolo
All,
I just watched a webcast where the presenter showed performing some
async work via using ThreadPool.QueueUserWorkItem(...). This call
uses thread from the .NET process thread pool to do some work in a
worker function. So far, so good.
In the webcast, the code in the worker function (the one the thread
from the thread pool runs in) directly updates the WinForm's UI (calls
update function on a progress bar control).
I've been programming in Win32 for longer than I care to admit --- and
this is generally a BAD THING to update a UI from any thread other
than the UI thread that created the control.
So, the questio is... Do the threads in the thread pool/the thread
pool itself do something special vis-a-vis interacting with the UI or
did the webcast's author overlook a potiential pitfall?
Thanks,
John
I just watched a webcast where the presenter showed performing some
async work via using ThreadPool.QueueUserWorkItem(...). This call
uses thread from the .NET process thread pool to do some work in a
worker function. So far, so good.
In the webcast, the code in the worker function (the one the thread
from the thread pool runs in) directly updates the WinForm's UI (calls
update function on a progress bar control).
I've been programming in Win32 for longer than I care to admit --- and
this is generally a BAD THING to update a UI from any thread other
than the UI thread that created the control.
So, the questio is... Do the threads in the thread pool/the thread
pool itself do something special vis-a-vis interacting with the UI or
did the webcast's author overlook a potiential pitfall?
Thanks,
John