Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to the
method that can run the job, and calling BeginInvoke on the method.
Throughout the job itself, we use the CallContext class to store information
that is needed by many classes in the call stream. This works well, and
concurrent threads are working fine.
What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the job that
just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information on the
CallContext is left over from the previous job (which has completed) - as
opposed to being cleared out.
Anyone know why the threads are being reused (especially without being
cleared out first) in this way?
10  1576 
Marina <so*****@nospam.com> wrote: Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to the
method that can run the job, and calling BeginInvoke on the method.
Throughout the job itself, we use the CallContext class to store information
that is needed by many classes in the call stream. This works well, and
concurrent threads are working fine.
What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the job that
just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information on the
CallContext is left over from the previous job (which has completed) - as
opposed to being cleared out.
Anyone know why the threads are being reused (especially without being
cleared out first) in this way?
I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
The problem with using the threadpool (that I've run into) is that if your
asynchronous delegate functions block, you basically lose a threadpool
thread and there's no way to kill it, as far as I know. If there is, please
let me know!
I realize that I shouldn't be calling functions that have the potential for
blocking forever, but these blocking calls are happening inside an API that
I have no control over.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Marina <so*****@nospam.com> wrote: Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to
the method that can run the job, and calling BeginInvoke on the method.
Throughout the job itself, we use the CallContext class to store
information that is needed by many classes in the call stream. This works well, and
concurrent threads are working fine.
What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the job
that just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information on
the CallContext is left over from the previous job (which has completed) -
as opposed to being cleared out.
Anyone know why the threads are being reused (especially without being
cleared out first) in this way?
I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Ok, thanks, that has shed some light onto the issue.
If creating an instance of the Thread class, and starting up a new thread
that way, would the same issue apply?
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Marina <so*****@nospam.com> wrote: Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to
the method that can run the job, and calling BeginInvoke on the method.
Throughout the job itself, we use the CallContext class to store
information that is needed by many classes in the call stream. This works well, and
concurrent threads are working fine.
What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the job
that just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information on
the CallContext is left over from the previous job (which has completed) -
as opposed to being cleared out.
Anyone know why the threads are being reused (especially without being
cleared out first) in this way?
I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Marina <so*****@nospam.com> wrote: Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to the
method that can run the job, and calling BeginInvoke on the method.
Throughout the job itself, we use the CallContext class to store information
that is needed by many classes in the call stream. This works well, and
concurrent threads are working fine.
What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the job that
just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information on the
CallContext is left over from the previous job (which has completed) - as
opposed to being cleared out.
Anyone know why the threads are being reused (especially without being
cleared out first) in this way?
I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Mike V" <a-mikeva@microsoft dawt com> wrote in message
news:e4**************@TK2MSFTNGP12.phx.gbl... The problem with using the threadpool (that I've run into) is that if your
asynchronous delegate functions block, you basically lose a threadpool
thread and there's no way to kill it, as far as I know. If there is,
please let me know!
I realize that I shouldn't be calling functions that have the potential
for blocking forever, but these blocking calls are happening inside an API
that I have no control over.
Then this would be a good reason not to call that API from a thread pool
thread, wouldn't it?
--
John Saunders
John.Saunders at SurfControl.com
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Marina <so*****@nospam.com> wrote: Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate
to the method that can run the job, and calling BeginInvoke on the method.
Throughout the job itself, we use the CallContext class to store information that is needed by many classes in the call stream. This works well,
and concurrent threads are working fine.
What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the
job that just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information
on the CallContext is left over from the previous job (which has completed) - as opposed to being cleared out.
Anyone know why the threads are being reused (especially without being
cleared out first) in this way?
I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
The problem with using the threadpool (that I've run into) is that if your
asynchronous delegate functions block, you basically lose a threadpool
thread and there's no way to kill it, as far as I know. If there is, please
let me know!
I realize that I shouldn't be calling functions that have the potential for
blocking forever, but these blocking calls are happening inside an API that
I have no control over.
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Marina <so*****@nospam.com> wrote: Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to
the method that can run the job, and calling BeginInvoke on the method.
Throughout the job itself, we use the CallContext class to store
information that is needed by many classes in the call stream. This works well, and
concurrent threads are working fine.
What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the job
that just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information on
the CallContext is left over from the previous job (which has completed) -
as opposed to being cleared out.
Anyone know why the threads are being reused (especially without being
cleared out first) in this way?
I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Ok, thanks, that has shed some light onto the issue.
If creating an instance of the Thread class, and starting up a new thread
that way, would the same issue apply?
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Marina <so*****@nospam.com> wrote: Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to
the method that can run the job, and calling BeginInvoke on the method.
Throughout the job itself, we use the CallContext class to store
information that is needed by many classes in the call stream. This works well, and
concurrent threads are working fine.
What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the job
that just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information on
the CallContext is left over from the previous job (which has completed) -
as opposed to being cleared out.
Anyone know why the threads are being reused (especially without being
cleared out first) in this way?
I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Mike V" <a-mikeva@microsoft dawt com> wrote in message
news:e4**************@TK2MSFTNGP12.phx.gbl... The problem with using the threadpool (that I've run into) is that if your
asynchronous delegate functions block, you basically lose a threadpool
thread and there's no way to kill it, as far as I know. If there is,
please let me know!
I realize that I shouldn't be calling functions that have the potential
for blocking forever, but these blocking calls are happening inside an API
that I have no control over.
Then this would be a good reason not to call that API from a thread pool
thread, wouldn't it?
--
John Saunders
John.Saunders at SurfControl.com
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Marina <so*****@nospam.com> wrote: Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate
to the method that can run the job, and calling BeginInvoke on the method.
Throughout the job itself, we use the CallContext class to store information that is needed by many classes in the call stream. This works well,
and concurrent threads are working fine.
What happens is, that after a job is done, and another one is started,
sometimes, the new job, is being executed on the same thread as the
job that just finished (i.e., they have the same thread id). So it looks like
threads are being reused by subsequent jobs - and so the information
on the CallContext is left over from the previous job (which has completed) - as opposed to being cleared out.
Anyone know why the threads are being reused (especially without being
cleared out first) in this way?
I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Yes, which is exactly why I have to rewrite many lines of code to use
Threading.Threads instead of asynchronous delegates. Asynchronous delegates
are much more convenient for parameter passing and returning values.
"John Saunders" <john.saunders at SurfControl.com> wrote in message
news:#v**************@tk2msftngp13.phx.gbl... "Mike V" <a-mikeva@microsoft dawt com> wrote in message
news:e4**************@TK2MSFTNGP12.phx.gbl... The problem with using the threadpool (that I've run into) is that if
your asynchronous delegate functions block, you basically lose a threadpool
thread and there's no way to kill it, as far as I know. If there is, please let me know!
I realize that I shouldn't be calling functions that have the potential
for blocking forever, but these blocking calls are happening inside an API
that I have no control over.
Then this would be a good reason not to call that API from a thread pool
thread, wouldn't it?
--
John Saunders
John.Saunders at SurfControl.com
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Marina <so*****@nospam.com> wrote:
> Hi, we have an app, that executes jobs submitted from an outside
> application. It executes them asynchronusly, by creating a delegate to the > method that can run the job, and calling BeginInvoke on the method.
>
> Throughout the job itself, we use the CallContext class to store
information > that is needed by many classes in the call stream. This works well,
and > concurrent threads are working fine.
>
> What happens is, that after a job is done, and another one is
started, > sometimes, the new job, is being executed on the same thread as the
job that > just finished (i.e., they have the same thread id). So it looks
like > threads are being reused by subsequent jobs - and so the information
on the > CallContext is left over from the previous job (which has
completed) - as > opposed to being cleared out.
>
> Anyone know why the threads are being reused (especially without
being > cleared out first) in this way?
I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Yes, which is exactly why I have to rewrite many lines of code to use
Threading.Threads instead of asynchronous delegates. Asynchronous delegates
are much more convenient for parameter passing and returning values.
"John Saunders" <john.saunders at SurfControl.com> wrote in message
news:#v**************@tk2msftngp13.phx.gbl... "Mike V" <a-mikeva@microsoft dawt com> wrote in message
news:e4**************@TK2MSFTNGP12.phx.gbl... The problem with using the threadpool (that I've run into) is that if
your asynchronous delegate functions block, you basically lose a threadpool
thread and there's no way to kill it, as far as I know. If there is, please let me know!
I realize that I shouldn't be calling functions that have the potential
for blocking forever, but these blocking calls are happening inside an API
that I have no control over.
Then this would be a good reason not to call that API from a thread pool
thread, wouldn't it?
--
John Saunders
John.Saunders at SurfControl.com
"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om... Marina <so*****@nospam.com> wrote:
> Hi, we have an app, that executes jobs submitted from an outside
> application. It executes them asynchronusly, by creating a delegate to the > method that can run the job, and calling BeginInvoke on the method.
>
> Throughout the job itself, we use the CallContext class to store
information > that is needed by many classes in the call stream. This works well,
and > concurrent threads are working fine.
>
> What happens is, that after a job is done, and another one is
started, > sometimes, the new job, is being executed on the same thread as the
job that > just finished (i.e., they have the same thread id). So it looks
like > threads are being reused by subsequent jobs - and so the information
on the > CallContext is left over from the previous job (which has
completed) - as > opposed to being cleared out.
>
> Anyone know why the threads are being reused (especially without
being > cleared out first) in this way?
I don't know about the clearing bit, but threads are reused because
BeginInvoke uses the ThreadPool. This is usually a very good thing, as
creating threads is a relatively expensive task.
--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Marina |
last post by:
Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to the
method that can run the job, and calling BeginInvoke on...
|
by: Marina |
last post by:
Hi, we have an app, that executes jobs submitted from an outside
application. It executes them asynchronusly, by creating a delegate to the
method that can run the job, and calling BeginInvoke on...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |
