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

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.

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).

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.

As far as your specific problem goes, there's no point in complaining that SSH isn't supported in .NET (assuming it's not...I know .NET does have a lot of crypto stuff in it, and it's possible that you could easily write an SSH implementation just by combining that with the usual network i/o stuff). .NET can't possibly implement _everything_, even as with each iteration it does support more and more.

If a specific library isn't doing what you need or want, you can either find a different library or write it yourself. Programmers all over the world make these kinds of decisions every day, and it's just not a big deal. Note that you are not limited to using a managed code library. With p/invoke you should be able to use pretty much whatever library you find useful.

I will point out that your assertion that Microsoft could publish an SSH library "in a few weeks time" is absurd. No reputable software publishing company does _anything_ "in a few weeks time". It would take _way_ more than a few weeks just to properly _test_ such a library, never mind implement it correctly. Granted I have very little specific knowledge of SSH, but I would guess that it would take at least three staff members (programmer, tester, and a program manager to manage the specification for the feature) something like 6-12 months, for a potential cost of up to three man-years.

Even if it _were_ just a few weeks worth of work, it boggles my mind that you would on the one hand say that Microsoft should do this work, and on the other hand write "My employer is not going to want me to spend several weeks to write my own". Don't you think Microsoft already has their own things they are trying to get done? Surely if this is an important enough feature for your need to justify them implementing it, it's important enough to justify _you_ doing whatever work is needed on your own to get it into your product.

Maybe it will get into .NET eventually, maybe it won't. But making fanciful claims about how easy it would be to implement doesn't help your case any. If it's really that easy, write it yourself.

And please keep in mind that designing and implementing an operating system is a lot harder than you seem to think it is. I think it's safe to say that if dealing with hung threads were really as easy as you claim it is, Windows and every other OS would already do it. But there's not a single OS I can think of off the top of my head that can allow a thread or process to be safely terminated without the risk of causing data integrity problems.

Pete
.