Using .NET 1.1.
We have a mixed-mode assembly written in Managed C++ that we are using from
an ASP.NET application that has been coded using C#. The mixed-mode assembly
has its own "initialisation" routine to cater for any potential "mixed-mode
DLL loading problem".
Some of our code uses thread-local-storage, and in the DllMain for my
mixed-mode assembly I did the appropriate initialisation of the
thread-local-storage object on THREAD_ATTACH, cleaning it up on
THREAD_DETACH.
When the assembly is used from ASP.NET, I don't see the THREAD_ATTACH or
DETACH.
Now I understand from reading Microsoft's documentation that
THREAD_ATTACH/DETACH are not posted to DllMain for pre-existing threads.
Looking at aspnet_wp.exe, on my machine (WXP Pro), it starts with 14 threads
and when I start a couple of web requests the number of threads increases to
17. Fairly soon my assembly fails because it is attempting to use the
thread-local-storage but the slot has not been initialised.
My workaround for the moment is to perform allocation of the
thread-local-storage object when it is requested, if it is not already
present, but I don't like this approach because if I don't see the
THREAD_ATTACH/DETACH I'll never know when to clean it up.
The most confusing thing is understanding how aspnet_wp.exe can create a new
thread but those threads don't produce corresponding THREAD_ATTACH'es in my
assembly.
Does anyone have any experience with this who might be able to offer an
explanation?
Thanks
Kevin
7  1402 
"Kevin Frey" <ke**********@hotmail.com> wrote in message
news:Oc**************@TK2MSFTNGP10.phx.gbl... The most confusing thing is understanding how aspnet_wp.exe can create a
new thread but those threads don't produce corresponding THREAD_ATTACH'es
in my assembly.
You might want to post in an ASP.Net group.
But a possible explanation is that ASP.Net creates a thread pool in advance
of loading your assembly. Then it assigns a thread as necessary from the
pool to service the request which passes through your assembly. If that's
the case, you won't see the thread attach notification.
Regards,
Will
I'm also suspecting that the CLR is using DisableThreadLibraryCalls since I
know for a fact that the aspnet_wp.exe creates additional threads and I
don't see any notifications.
Kevin
"William DePalo [MVP VC++]" <wi***********@mvps.org> wrote in message
news:uy*************@TK2MSFTNGP15.phx.gbl... "Kevin Frey" <ke**********@hotmail.com> wrote in message
news:Oc**************@TK2MSFTNGP10.phx.gbl... The most confusing thing is understanding how aspnet_wp.exe can create a
new thread but those threads don't produce corresponding THREAD_ATTACH'es
in my assembly.
You might want to post in an ASP.Net group.
But a possible explanation is that ASP.Net creates a thread pool in
advance of loading your assembly. Then it assigns a thread as necessary
from the pool to service the request which passes through your assembly.
If that's the case, you won't see the thread attach notification.
Regards,
Will
No, the CLR doesn't use DisableThreadLibraryCalls.
What's happening is, that the worker process uses a pool of threads, when
the "very first" web request arrives, the poolmanager creates a minimum of
pooled threads (default is 3 for IIS5) and pulls a thread from the pool to
handle the request. Your request handler loads the DLL (delay loaded) as a
result of a call into your dll, but that's is after the minimum pool of
threads are created, so you don't see any DLL_THREAD_ATTACH. When the
request finishes, the thread returns to the pool where it wait's to handle
up-comming requests. That means that you won't see any DLL_THREAD_ATTACH as
long as there are free threads in the pool.
Willy.
"Kevin Frey" <ke**********@hotmail.com> wrote in message
news:eg*************@tk2msftngp13.phx.gbl...
| I'm also suspecting that the CLR is using DisableThreadLibraryCalls since
I
| know for a fact that the aspnet_wp.exe creates additional threads and I
| don't see any notifications.
|
| Kevin
|
| "William DePalo [MVP VC++]" <wi***********@mvps.org> wrote in message
| news:uy*************@TK2MSFTNGP15.phx.gbl...
| > "Kevin Frey" <ke**********@hotmail.com> wrote in message
| > news:Oc**************@TK2MSFTNGP10.phx.gbl...
| >> The most confusing thing is understanding how aspnet_wp.exe can create
a
| >> new thread but those threads don't produce corresponding
THREAD_ATTACH'es
| >> in my assembly.
| >
| > You might want to post in an ASP.Net group.
| >
| > But a possible explanation is that ASP.Net creates a thread pool in
| > advance of loading your assembly. Then it assigns a thread as necessary
| > from the pool to service the request which passes through your assembly.
| > If that's the case, you won't see the thread attach notification.
| >
| > Regards,
| > Will
| >
| >
| >
|
|
OK. Thanks. So are you saying that IIS is creating the threads, not the
ASP.NET framework? If so, I'm confused, because aspnet_wp.exe is *not* IIS
and that's where I am seeing extra threads being created. Actually, thinking
about it a little, my confusion is even greater, because usually
"extensions" to IIS are in the form of an ISAPI DLL, yet here is an
*executable* getting run (somehow) by IIS. It's a side issue - but do you
know the process by which all this starts running?
Anyway, regardless of why I'm not getting the THREAD_ATTACH/DETACH
notifications, I still have a problem to solve, hence my next question...
If you wanted to use Thread-Local-Storage, then the absence of THREAD_ATTACH
notifications prevents you from initialising a "thread local storage object"
in advance. That's fine, because it can be solved just as easily with "lazy
instantiation" (eg. if p == null then instantiate the object).
Unfortunately the reverse is not true in terms of cleaning up these objects.
Since there is no THREAD_DETACH notification, there is no logical point (as
far as a .NET assembly is concerned) for cleaning up the thread's thread
local storage object. At the moment we are just letting it leak, until we
think of an idea.
How dangerous the leak is I guess depends on whether IIS or ASP.NET
terminates threads from the pool and then recreates them. In other words,
does the thread pool grow *and* shrink? Or does it only ever grow?
If the thread pool does shrink as well, then over time our memory leak could
become a problem (although the object in question is only about 30 bytes in
size, so it will require a large amount of threads to start/stop before
having any discernible memory impact).
So do you happen to have a plan of attack for handling this problem?
Thanks
Kevin
"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... No, the CLR doesn't use DisableThreadLibraryCalls.
What's happening is, that the worker process uses a pool of threads, when
the "very first" web request arrives, the poolmanager creates a minimum of
pooled threads (default is 3 for IIS5) and pulls a thread from the pool to
handle the request. Your request handler loads the DLL (delay loaded) as a
result of a call into your dll, but that's is after the minimum pool of
threads are created, so you don't see any DLL_THREAD_ATTACH. When the
request finishes, the thread returns to the pool where it wait's to handle
up-comming requests. That means that you won't see any DLL_THREAD_ATTACH
as
long as there are free threads in the pool.
Willy.
"Kevin Frey" <ke**********@hotmail.com> wrote in message
news:eg*************@tk2msftngp13.phx.gbl...
| I'm also suspecting that the CLR is using DisableThreadLibraryCalls
since
I
| know for a fact that the aspnet_wp.exe creates additional threads and I
| don't see any notifications.
|
| Kevin
|
| "William DePalo [MVP VC++]" <wi***********@mvps.org> wrote in message
| news:uy*************@TK2MSFTNGP15.phx.gbl...
| > "Kevin Frey" <ke**********@hotmail.com> wrote in message
| > news:Oc**************@TK2MSFTNGP10.phx.gbl...
| >> The most confusing thing is understanding how aspnet_wp.exe can
create
a
| >> new thread but those threads don't produce corresponding
THREAD_ATTACH'es
| >> in my assembly.
| >
| > You might want to post in an ASP.Net group.
| >
| > But a possible explanation is that ASP.Net creates a thread pool in
| > advance of loading your assembly. Then it assigns a thread as
necessary
| > from the pool to service the request which passes through your
assembly.
| > If that's the case, you won't see the thread attach notification.
| >
| > Regards,
| > Will
| >
| >
| >
|
|
"Kevin Frey" <ke**********@hotmail.com> wrote in message
news:Or**************@TK2MSFTNGP11.phx.gbl...
| OK. Thanks. So are you saying that IIS is creating the threads, not the
| ASP.NET framework? If so, I'm confused, because aspnet_wp.exe is *not* IIS
| and that's where I am seeing extra threads being created. Actually,
thinking
| about it a little, my confusion is even greater, because usually
| "extensions" to IIS are in the form of an ISAPI DLL, yet here is an
| *executable* getting run (somehow) by IIS. It's a side issue - but do you
| know the process by which all this starts running?
|
No, I'm talking about the "worker process" which is "aspnet_wp.exe" on W2K
and XP (different name different architecture on W2K3).
The "worker process" is handling all "asp.net" requests and it's started and
fed by the .NET ISAPI extension (aspnet_filter.dll), communication between
IIS (actually the ISAPI filter) and the worker process goes via a named
pipe.
| Anyway, regardless of why I'm not getting the THREAD_ATTACH/DETACH
| notifications, I still have a problem to solve, hence my next question...
|
| If you wanted to use Thread-Local-Storage, then the absence of
THREAD_ATTACH
| notifications prevents you from initialising a "thread local storage
object"
| in advance. That's fine, because it can be solved just as easily with
"lazy
| instantiation" (eg. if p == null then instantiate the object).
|
| Unfortunately the reverse is not true in terms of cleaning up these
objects.
| Since there is no THREAD_DETACH notification, there is no logical point
(as
| far as a .NET assembly is concerned) for cleaning up the thread's thread
| local storage object. At the moment we are just letting it leak, until we
| think of an idea.
|
| How dangerous the leak is I guess depends on whether IIS or ASP.NET
| terminates threads from the pool and then recreates them. In other words,
| does the thread pool grow *and* shrink? Or does it only ever grow?
|
The thread pool grows until it reaches the maximum threads (25 per CPU by
default but configurable), incomming requests are queued and picked up by a
free thread from the pool until the maximum number of threads is reached and
all threads are busy, that's the point where requests may get delayed. That
means that threads live as long as the application domain related to the web
application.
Whenever the worker process detects an application failure (out-of
memory/stack, whatever) or a deadlock at the level of the thread pool, it
will recycle the AD, that is, it unloads the AD which implicitely aborts all
threads (and releases the TLS) and unloads all assemblies loaded into this
AD, after that the worker recreate the AD for the application and waits for
new requests to arrive.
So, that means that the threads are kept alive as long as the AD exists, no
new threads are getting created, instead the existing threads are pulled
from the pool over and over again until the whole thing gets torned down.
Note that the AD is also unloaded after a time-out period during which no
new requests arrived.
| If the thread pool does shrink as well, then over time our memory leak
could
| become a problem (although the object in question is only about 30 bytes
in
| size, so it will require a large amount of threads to start/stop before
| having any discernible memory impact).
|
If, you read the above (and I hope I made it clear), you'll understand that
there is no issue (well I don't see any) with TLS in asp.net.
Willy.
| So do you happen to have a plan of attack for handling this problem?
|
| Thanks
|
| Kevin
|
| "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
| news:%2****************@TK2MSFTNGP10.phx.gbl...
| > No, the CLR doesn't use DisableThreadLibraryCalls.
| > What's happening is, that the worker process uses a pool of threads,
when
| > the "very first" web request arrives, the poolmanager creates a minimum
of
| > pooled threads (default is 3 for IIS5) and pulls a thread from the pool
to
| > handle the request. Your request handler loads the DLL (delay loaded) as
a
| > result of a call into your dll, but that's is after the minimum pool of
| > threads are created, so you don't see any DLL_THREAD_ATTACH. When the
| > request finishes, the thread returns to the pool where it wait's to
handle
| > up-comming requests. That means that you won't see any DLL_THREAD_ATTACH
| > as
| > long as there are free threads in the pool.
| >
| > Willy.
| >
| > "Kevin Frey" <ke**********@hotmail.com> wrote in message
| > news:eg*************@tk2msftngp13.phx.gbl...
| > | I'm also suspecting that the CLR is using DisableThreadLibraryCalls
| > since
| > I
| > | know for a fact that the aspnet_wp.exe creates additional threads and
I
| > | don't see any notifications.
| > |
| > | Kevin
| > |
| > | "William DePalo [MVP VC++]" <wi***********@mvps.org> wrote in message
| > | news:uy*************@TK2MSFTNGP15.phx.gbl...
| > | > "Kevin Frey" <ke**********@hotmail.com> wrote in message
| > | > news:Oc**************@TK2MSFTNGP10.phx.gbl...
| > | >> The most confusing thing is understanding how aspnet_wp.exe can
| > create
| > a
| > | >> new thread but those threads don't produce corresponding
| > THREAD_ATTACH'es
| > | >> in my assembly.
| > | >
| > | > You might want to post in an ASP.Net group.
| > | >
| > | > But a possible explanation is that ASP.Net creates a thread pool in
| > | > advance of loading your assembly. Then it assigns a thread as
| > necessary
| > | > from the pool to service the request which passes through your
| > assembly.
| > | > If that's the case, you won't see the thread attach notification.
| > | >
| > | > Regards,
| > | > Will
| > | >
| > | >
| > | >
| > |
| > |
| >
| >
|
|
Thanks, Willy. I wish I could have found such a fantastically clear
explanation of this on the web. You've been a great help.
Thanks
Kevin
"Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
news:OL**************@tk2msftngp13.phx.gbl...
"Kevin Frey" <ke**********@hotmail.com> wrote in message
news:Or**************@TK2MSFTNGP11.phx.gbl...
| OK. Thanks. So are you saying that IIS is creating the threads, not the
| ASP.NET framework? If so, I'm confused, because aspnet_wp.exe is *not*
IIS
| and that's where I am seeing extra threads being created. Actually,
thinking
| about it a little, my confusion is even greater, because usually
| "extensions" to IIS are in the form of an ISAPI DLL, yet here is an
| *executable* getting run (somehow) by IIS. It's a side issue - but do
you
| know the process by which all this starts running?
|
No, I'm talking about the "worker process" which is "aspnet_wp.exe" on W2K
and XP (different name different architecture on W2K3).
The "worker process" is handling all "asp.net" requests and it's started
and
fed by the .NET ISAPI extension (aspnet_filter.dll), communication between
IIS (actually the ISAPI filter) and the worker process goes via a named
pipe.
| Anyway, regardless of why I'm not getting the THREAD_ATTACH/DETACH
| notifications, I still have a problem to solve, hence my next
question...
|
| If you wanted to use Thread-Local-Storage, then the absence of
THREAD_ATTACH
| notifications prevents you from initialising a "thread local storage
object"
| in advance. That's fine, because it can be solved just as easily with
"lazy
| instantiation" (eg. if p == null then instantiate the object).
|
| Unfortunately the reverse is not true in terms of cleaning up these
objects.
| Since there is no THREAD_DETACH notification, there is no logical point
(as
| far as a .NET assembly is concerned) for cleaning up the thread's thread
| local storage object. At the moment we are just letting it leak, until
we
| think of an idea.
|
| How dangerous the leak is I guess depends on whether IIS or ASP.NET
| terminates threads from the pool and then recreates them. In other
words,
| does the thread pool grow *and* shrink? Or does it only ever grow?
|
The thread pool grows until it reaches the maximum threads (25 per CPU by
default but configurable), incomming requests are queued and picked up by
a
free thread from the pool until the maximum number of threads is reached
and
all threads are busy, that's the point where requests may get delayed.
That
means that threads live as long as the application domain related to the
web
application.
Whenever the worker process detects an application failure (out-of
memory/stack, whatever) or a deadlock at the level of the thread pool, it
will recycle the AD, that is, it unloads the AD which implicitely aborts
all
threads (and releases the TLS) and unloads all assemblies loaded into this
AD, after that the worker recreate the AD for the application and waits
for
new requests to arrive.
So, that means that the threads are kept alive as long as the AD exists,
no
new threads are getting created, instead the existing threads are pulled
from the pool over and over again until the whole thing gets torned down.
Note that the AD is also unloaded after a time-out period during which no
new requests arrived.
| If the thread pool does shrink as well, then over time our memory leak
could
| become a problem (although the object in question is only about 30 bytes
in
| size, so it will require a large amount of threads to start/stop before
| having any discernible memory impact).
|
If, you read the above (and I hope I made it clear), you'll understand
that
there is no issue (well I don't see any) with TLS in asp.net.
Willy.
| So do you happen to have a plan of attack for handling this problem?
|
| Thanks
|
| Kevin
|
| "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
| news:%2****************@TK2MSFTNGP10.phx.gbl...
| > No, the CLR doesn't use DisableThreadLibraryCalls.
| > What's happening is, that the worker process uses a pool of threads,
when
| > the "very first" web request arrives, the poolmanager creates a
minimum
of
| > pooled threads (default is 3 for IIS5) and pulls a thread from the
pool
to
| > handle the request. Your request handler loads the DLL (delay loaded)
as
a
| > result of a call into your dll, but that's is after the minimum pool
of
| > threads are created, so you don't see any DLL_THREAD_ATTACH. When the
| > request finishes, the thread returns to the pool where it wait's to
handle
| > up-comming requests. That means that you won't see any
DLL_THREAD_ATTACH
| > as
| > long as there are free threads in the pool.
| >
| > Willy.
| >
| > "Kevin Frey" <ke**********@hotmail.com> wrote in message
| > news:eg*************@tk2msftngp13.phx.gbl...
| > | I'm also suspecting that the CLR is using DisableThreadLibraryCalls
| > since
| > I
| > | know for a fact that the aspnet_wp.exe creates additional threads
and
I
| > | don't see any notifications.
| > |
| > | Kevin
| > |
| > | "William DePalo [MVP VC++]" <wi***********@mvps.org> wrote in
message
| > | news:uy*************@TK2MSFTNGP15.phx.gbl...
| > | > "Kevin Frey" <ke**********@hotmail.com> wrote in message
| > | > news:Oc**************@TK2MSFTNGP10.phx.gbl...
| > | >> The most confusing thing is understanding how aspnet_wp.exe can
| > create
| > a
| > | >> new thread but those threads don't produce corresponding
| > THREAD_ATTACH'es
| > | >> in my assembly.
| > | >
| > | > You might want to post in an ASP.Net group.
| > | >
| > | > But a possible explanation is that ASP.Net creates a thread pool
in
| > | > advance of loading your assembly. Then it assigns a thread as
| > necessary
| > | > from the pool to service the request which passes through your
| > assembly.
| > | > If that's the case, you won't see the thread attach notification.
| > | >
| > | > Regards,
| > | > Will
| > | >
| > | >
| > | >
| > |
| > |
| >
| >
|
|
Kevin, glad to help you out, thanks for the kind words.
Willy.
"Kevin Frey" <ke**********@hotmail.com> wrote in message
news:Op**************@tk2msftngp13.phx.gbl...
| Thanks, Willy. I wish I could have found such a fantastically clear
| explanation of this on the web. You've been a great help.
|
| Thanks
|
| Kevin
|
| "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
| news:OL**************@tk2msftngp13.phx.gbl...
| >
| >
| >
| > "Kevin Frey" <ke**********@hotmail.com> wrote in message
| > news:Or**************@TK2MSFTNGP11.phx.gbl...
| > | OK. Thanks. So are you saying that IIS is creating the threads, not
the
| > | ASP.NET framework? If so, I'm confused, because aspnet_wp.exe is *not*
| > IIS
| > | and that's where I am seeing extra threads being created. Actually,
| > thinking
| > | about it a little, my confusion is even greater, because usually
| > | "extensions" to IIS are in the form of an ISAPI DLL, yet here is an
| > | *executable* getting run (somehow) by IIS. It's a side issue - but do
| > you
| > | know the process by which all this starts running?
| > |
| >
| > No, I'm talking about the "worker process" which is "aspnet_wp.exe" on
W2K
| > and XP (different name different architecture on W2K3).
| > The "worker process" is handling all "asp.net" requests and it's started
| > and
| > fed by the .NET ISAPI extension (aspnet_filter.dll), communication
between
| > IIS (actually the ISAPI filter) and the worker process goes via a named
| > pipe.
| >
| > | Anyway, regardless of why I'm not getting the THREAD_ATTACH/DETACH
| > | notifications, I still have a problem to solve, hence my next
| > question...
| > |
| > | If you wanted to use Thread-Local-Storage, then the absence of
| > THREAD_ATTACH
| > | notifications prevents you from initialising a "thread local storage
| > object"
| > | in advance. That's fine, because it can be solved just as easily with
| > "lazy
| > | instantiation" (eg. if p == null then instantiate the object).
| > |
| > | Unfortunately the reverse is not true in terms of cleaning up these
| > objects.
| > | Since there is no THREAD_DETACH notification, there is no logical
point
| > (as
| > | far as a .NET assembly is concerned) for cleaning up the thread's
thread
| > | local storage object. At the moment we are just letting it leak, until
| > we
| > | think of an idea.
| > |
| > | How dangerous the leak is I guess depends on whether IIS or ASP.NET
| > | terminates threads from the pool and then recreates them. In other
| > words,
| > | does the thread pool grow *and* shrink? Or does it only ever grow?
| > |
| > The thread pool grows until it reaches the maximum threads (25 per CPU
by
| > default but configurable), incomming requests are queued and picked up
by
| > a
| > free thread from the pool until the maximum number of threads is reached
| > and
| > all threads are busy, that's the point where requests may get delayed.
| > That
| > means that threads live as long as the application domain related to the
| > web
| > application.
| > Whenever the worker process detects an application failure (out-of
| > memory/stack, whatever) or a deadlock at the level of the thread pool,
it
| > will recycle the AD, that is, it unloads the AD which implicitely aborts
| > all
| > threads (and releases the TLS) and unloads all assemblies loaded into
this
| > AD, after that the worker recreate the AD for the application and waits
| > for
| > new requests to arrive.
| > So, that means that the threads are kept alive as long as the AD exists,
| > no
| > new threads are getting created, instead the existing threads are pulled
| > from the pool over and over again until the whole thing gets torned
down.
| > Note that the AD is also unloaded after a time-out period during which
no
| > new requests arrived.
| >
| > | If the thread pool does shrink as well, then over time our memory leak
| > could
| > | become a problem (although the object in question is only about 30
bytes
| > in
| > | size, so it will require a large amount of threads to start/stop
before
| > | having any discernible memory impact).
| > |
| >
| > If, you read the above (and I hope I made it clear), you'll understand
| > that
| > there is no issue (well I don't see any) with TLS in asp.net.
| >
| > Willy.
| >
| >
| > | So do you happen to have a plan of attack for handling this problem?
| > |
| > | Thanks
| > |
| > | Kevin
| > |
| > | "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
| > | news:%2****************@TK2MSFTNGP10.phx.gbl...
| > | > No, the CLR doesn't use DisableThreadLibraryCalls.
| > | > What's happening is, that the worker process uses a pool of threads,
| > when
| > | > the "very first" web request arrives, the poolmanager creates a
| > minimum
| > of
| > | > pooled threads (default is 3 for IIS5) and pulls a thread from the
| > pool
| > to
| > | > handle the request. Your request handler loads the DLL (delay
loaded)
| > as
| > a
| > | > result of a call into your dll, but that's is after the minimum pool
| > of
| > | > threads are created, so you don't see any DLL_THREAD_ATTACH. When
the
| > | > request finishes, the thread returns to the pool where it wait's to
| > handle
| > | > up-comming requests. That means that you won't see any
| > DLL_THREAD_ATTACH
| > | > as
| > | > long as there are free threads in the pool.
| > | >
| > | > Willy.
| > | >
| > | > "Kevin Frey" <ke**********@hotmail.com> wrote in message
| > | > news:eg*************@tk2msftngp13.phx.gbl...
| > | > | I'm also suspecting that the CLR is using
DisableThreadLibraryCalls
| > | > since
| > | > I
| > | > | know for a fact that the aspnet_wp.exe creates additional threads
| > and
| > I
| > | > | don't see any notifications.
| > | > |
| > | > | Kevin
| > | > |
| > | > | "William DePalo [MVP VC++]" <wi***********@mvps.org> wrote in
| > message
| > | > | news:uy*************@TK2MSFTNGP15.phx.gbl...
| > | > | > "Kevin Frey" <ke**********@hotmail.com> wrote in message
| > | > | > news:Oc**************@TK2MSFTNGP10.phx.gbl...
| > | > | >> The most confusing thing is understanding how aspnet_wp.exe can
| > | > create
| > | > a
| > | > | >> new thread but those threads don't produce corresponding
| > | > THREAD_ATTACH'es
| > | > | >> in my assembly.
| > | > | >
| > | > | > You might want to post in an ASP.Net group.
| > | > | >
| > | > | > But a possible explanation is that ASP.Net creates a thread pool
| > in
| > | > | > advance of loading your assembly. Then it assigns a thread as
| > | > necessary
| > | > | > from the pool to service the request which passes through your
| > | > assembly.
| > | > | > If that's the case, you won't see the thread attach
notification.
| > | > | >
| > | > | > Regards,
| > | > | > Will
| > | > | >
| > | > | >
| > | > | >
| > | > |
| > | > |
| > | >
| > | >
| > |
| > |
| >
| >
|
|
This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Perttu Pulkkinen |
last post by:
No questions, but just consider if this is useful to you:-) but of course
feedback & corrections are welcome.
function php_mixed_to_js_value($jsname, $mixed)
{
if(is_null($mixed))
{ return "\n...
|
by: Swaroop Kumar |
last post by:
Hi:
I'm trying to write a schema that contains information as
described below:
1. The first element is a mandatory fixed string.
2. The second element is a mixed content element that can...
|
by: Paul A. Hoadley |
last post by:
Hello,
I am trying to convert a RELAX NG schema to DTD using Trang. I am
currently trying to add some inline elements to the schema, such as
<emph> for marking emphasised text. Here is an...
|
by: Bill Cohagan |
last post by:
I'm trying to generate class definitions from an XSD that contains something
like:
<xs:complexType name="foo" mixed="true">
<xs:choice minOccurs = "0" maxOccurs="unbounded">
<xs:element name =...
|
by: James Harris |
last post by:
Before I embark on a new long-term project I'd appreciate your advice on how to split up
long names. I would like to keep the standards for command names the same as that for
variable names....
|
by: Jeff |
last post by:
I am trying to crete a method that will convert an improper fraction to a
mixed number...
I am not sure how about how to acomplish this. I know I can get the
remainder with the modulus operator...
|
by: Garrek |
last post by:
I have an existing ASP.Net application that must be modified to support
mixed content: Latin-based languages (i.e. English) intermixed with
Arabic. Our code and database assumes everything is...
|
by: AG |
last post by:
Hi,
I have implemented the ASP.Net Ihttphandler interface. Handler references
the mixed dll (both managed/unmanaged code) that contains core C++ classes
wrapped under managed c++ wrappers....
|
by: Mali Guven |
last post by:
Hello,
I have a native DLL (written in C) which is supposed to call a managed DLL
(was written in C#, and an entry point was injected modifying the ildasm'd
code).
The exectuable calls the...
|
by: natG |
last post by:
Hi;
I am transferring data from MySql to db2 using my own java/jdbc program.
Working out ok, except for the fact that our apps use mixed-case names for
tables and columns. Although my CREATE TABLE...
|
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: 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: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
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: 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...
|
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,...
|
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...
| |
