Re: How do you kill a completely locked up thread?


"Peter Duniho" <NpOeStPeAdM@xxxxxxxxxxxxxxxx> wrote in message
news:op.t43lhtvz8jd0ej@xxxxxxxxxxxxxxxxxxxxxxx
On Thu, 17 Jan 2008 14:58:00 -0800, TheSilverHammer
<TheSilverHammer@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

If they can do it with processes, why can't they do it with threads?

Can do what with processes? We've already explained that you can't safely
terminate a process any more than you can safely abort a thread.

Sure you can. Ok, maybe not an arbitrary process, but it's fairly easy
(depending on what resources are required by your requirements) to design a
process that can be terminated at any point in time. It's even easier to
manage exiting your own process, even with hung threads. Theoretically you
can also create a thread that can be safely terminated, but... not with
..NET. .NET holds internal state and accesses it willy-nilly from any
threads in a way that's threadsafe but not abort safe. However, .NET
doesn't implement any external state on its own, only what you ask it to, so
you can manage your external resources in such a way that it's ok for the
process to be interrupted (for example, instead of writing data files that
could be left inconsistent, store your data in an ACID database using
transactions).


I am sure they can't guarantee that everything will be fine if my code
doesn't anticipate a resources disappearing, but if I do, I should be
able to
do it safely.

It's not an issue of resources "disappearing". It's an issue of them
being left in an inconsistent state.

There is no way for the _operating system_ to ensure that things are left
in an inconsistent state. Implementors of various data structures can do
things to make sure they are always in a consistent state (e.g. see
"journaled" or "transaction-based"), but that's up to the implementor.
The OS has no way to do this (though it might provide APIs to help an
implementor do it).

Yup, and the problem is that the .NET implementation uses hidden
process-local resources without doing any of this, so no matter what code
you tag on top, calling TerminateThread is gonna crash the process.


For example:

I have a MyThread and then I have the thread procedure which opens a
bunch
of files, sockets, and all that. If MyThread is killed, the OS can
recover
all that stuff.

No, it can't. All data within a process is owned by the _process_, unless
it's been specifically marked as thread data (*). The OS has no way to
know whether killing a thread allows that data to be cleaned up or not.

(*) (I'm not sure .NET supports this or not, but is supported in the
unmanaged Windows API...I'm seeing a Thread.AllocateDataSlot() method, and
I suspect this addresses the same issue in managed code. In any case,
note that it only addresses specific thread-local storage, not the OS
objects that might be referenced by that storage, as those are still
per-process and cannot be released with the thread terminates).

But even if it did have a way to know what data could be cleaned up,
_that's not the problem_. Cleaning things up is the least of the
worries. It's the fact that software _does_ stuff, and if it's
interrupted in the middle of _doing_ that stuff, whatever data the
software is operating on could be in an inconsistent state.

Most of your rant seems to be about this question of cleaning up, but
that's not the main problem. That's not what makes killing threads or
processes unsafe, and coming up with a paradigm in which you can ensure
things are cleaned up would _not_ make killing threads or processes a safe
operation.

One reasonable approach, as long as this SharpSSH library doesn't use any
external resources except sockets, would be to put that component in a
separate process, communicate back and forth with Remoting, and provide at
least one call that causes said process to free any shared resources and
then call ExitProcess (.NET Application.Exit?) to free the hung thread(s).


.

Relevant Pages

  • Re: C# Threading, and suspending or killing a thread
    ... Other threads that are spawned like this go right back to zero CPU, ... the Process Explorer to kill it there. ... When you terminate a thread in a .NET application you should consider the whole appdomain doomed, as in, you should no longer keep it around. ... - deadlocks, if the thread locks internal resources it will never unlock them, thus blocking future threads from ever accessing the resources the lock protects ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Why leave the error handling to the caller?
    ... does terminate with an error message on fail. ... Library routines have no business deciding to terminate ... That's rubbish because the above situation is on a modern medium to high spec notebook. ... On my previous company notebook which was high spec at the time I would also run out of resources. ...
    (comp.lang.c)
  • Re: how to destroy object from inside?
    ... terminate other resources owned by your class without waiting for the ... include a terminate method in your class which explicitly ... don't care when they get closed. ... >> You must get rid of all references pointing to your MyClass object. ...
    (comp.lang.java.programmer)
  • Re: WM_SETICON
    ... > process to terminate, I will have leaked a lot of objects. ... sense you can DestroyIcon and free the resources it consumes. ... it'll consume those resources ...
    (microsoft.public.win32.programmer.ui)