| In Win32 this works fine without trashing the kernel
NO it doesn't, these Win32 services are considered dangerous, designed to be
used with care and as I said in an earlier post designed to be used from a
debugger. Use them on modern large scale SMP boxes and your process may fail
when stressed unless you know exactly what you are doing and take some
measures. This is exactly what the SQL server team has been doing when they
integrated the CLR, they don't allow you creating threads in managed code
(unless you flag the assembly as unsafe) they don't use the CLR threadpool
they use their own, nor do they use the CLR memory manager (albeit they use
the GC) and last but not least, they load the SQLCLR code into a separate
domain that they can throw away when something bad hapens, the user only has
to provide a transaction and things aren't too bad when disaster comes
along.
, in .NET we need the
| same capability. Which we would have if ms didn't try to do mapping of
..net
| threads to underlying os threads. (Is this mapping really a good idea in
all
| cases, as now what would have worked, no longer does).
|
And to what would you map these things, .NET is an API and a run-time not an
OS nor an OS subsystem.
| If .NET is going to make it's own threads,
How do you want .NET to make his own threads? Do you want to bypass the OS
entirely.
we need a way to control them in
| a safe way, and suspend should suspend when safe for the CLR runtime, it
can
| ignore users own code and leave deadlock handling to the app developer in
| that case. But the CLR should not die.
The CLR is not a distinct part in the system, it's just a bunch of libraries
loaded into your process (a run-time) offering some services like JIT
compiling, automatic memory management etc...., the CLR can't die, your
process will die or better it won't make progress as it may deadlock.
There seem to be suggestions the CLR
| even has an issue not suspending in the right place (while that is not a
| problem for Win32).
Win32 has the same issues believe me, as I said before, see the description
of the SuspendThread API in MSDN. SuspendThread should only be used from
debuggers, user programs should signal the target thread to suspend itself,
but you should never call SuspendThread to suspend another thread.
Also, keep in mind that since these API's were invented things have changed
dramatically, superscallar HT and multicore CPU's did not exists, same for
APIC used these day's.
|
| In the scenario I am looking at I might only need to make local method
| calls and maybe one system call other than suspend that should be safe.
|
| Either fix the suspend so it suspends properly or if it does and they are
| really just worried about users hurting themselves,
There is nothing to fix, simply don't use it to suspend another thread.
Don't suspend a thread that runs third party code you don't control, you
actually don't know what the code looks like it might hold a kernel lock (or
shiver a loader lock), don't expect Suspend to stop the thread cold at a
safe point (whatever that may be in your third party code), it isn't even
guaranteed that the target thread immediately stops executing user code
after the SuspendThread API returns (on HT or multicores it won't unless you
call Win32 GetThreadContext after SuspendThread, bet you don't do this in
your native code!).
I only have to say is
| please don't hide the emergency break in my car because you think I might
use
| it and stop the car at the wrong time and damage something, I might need
that
| thing one day; Sure it would be dangerous to use that to stop the car
rather
| than my regular breaks... but if I don't have my regular breaks I want
| something to try to stop me
Don't know about "emergency breaks" in a car, all I know is a "hand break"
which is also not designed to stop a moving car.
Willy.