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  1618 
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.co m> 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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com... 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.co m>
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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com... 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.co m>
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.co m> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Mike V" <a-mikeva@microsof t dawt com> wrote in message
news:e4******** ******@TK2MSFTN GP12.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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com... 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.co m>
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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com... 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.co m>
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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com... 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.co m>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Mike V" <a-mikeva@microsof t dawt com> wrote in message
news:e4******** ******@TK2MSFTN GP12.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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com... 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.co m>
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.Threa ds instead of asynchronous delegates. Asynchronous delegates
are much more convenient for parameter passing and returning values.
"John Saunders" <john.saunder s at SurfControl.com > wrote in message
news:#v******** ******@tk2msftn gp13.phx.gbl... "Mike V" <a-mikeva@microsof t dawt com> wrote in message
news:e4******** ******@TK2MSFTN GP12.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.co m> wrote in message
news:MP******** *************** *@msnews.micros oft.com... 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.co m>
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 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,...
|
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 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,...
|
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, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
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 tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth.
The Art of Business Website Design
Your website is...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
| | |
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, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert into image.
Globals.ThisAddIn.Application.ActiveDocument.Select();...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
