Killing threads in C#

[W]

I have been unable to find a way to forcibly kill a thread that's in a blocking call. Is there a way? I am writing a console application, and one of the threads calls Console.ReadLine()
Now, on some condition that may occur in another thread, this thread need to be aborted, and immediately, not waiting for the user to press enter. mythread.Abort() does NOT work, as the thread then goes to the AbortRequested state and still waits for the user to press enter.

HELP

[queball]

I don't know C#, how can I reproduce this?
This prints "Exiting thread", on Mono at least:

using System;
using System.Threading;
public class Test : Object {
  public static void Main() {
    Thread thread=new Thread(new ThreadStart(Repeat));
    thread.Start();
    Thread.Sleep(100);
    thread.Abort();
  }
  
  public static void Repeat() {
    try {
      Console.WriteLine(Console.ReadLine());
    } finally {   
      Console.WriteLine("Exiting thread");
    }
  }
}

[W]

There's no sleep, but there is suspend, but that doesn't work either.

PHP Code:

using System;
using System.Threading;
public class Test{
        static void Main(string[] args)
        {
        Test me=new Test();
                Thread mythread=new Thread(new Threadstart(me.Read));
                mythread.Start();
                mythread.Suspend(); // This just freezes the thread, but it's still there.
                mythread.Resume();
                mythread.Abort(); // Still waits for input to finish
                mythread.Interupt(); // Does nothing, ReadLine is not interupted
        }

        public void Read()
        {
                Console.ReadLine();
        }
} 


[Weeks]

is c# any good then W?

[W]

Originally posted by Weeks
is c# any good then W?

It's ok, as languages go. Kinda like java, without all the **** parts. Haven't really done enough to get a feel for the performance.

[Raging.Retard]

Originally posted by W
There's no sleep

There is. The Sleep() method is static, and thus called within the thread itself rather than on an instance of a thread.

Originally posted by W
mythread.Abort(); // Still waits for input to finish

The Abort() method doesnt actually kill the thread. What happens is the method raises an exception (ThreadAbortException) inside the thread, with the purpose of eventually aborting it. It does not cause the thread to terminate there and then.

Re-reading your first post again, it sounds like you already knew that, appologies if im repeating.

However, what you probably hadn't realised, is that if Abort() is called whilst unmanaged code is running, the thread ignores the exception. The framework then re-throws the exception when the thread begins executing managed code again. I have a feeling the IO routines for console IO may not run in the context of managed code (speculation). If this is the case, there is not a great deal you can do about, bar creating your own ReadLine() method using standard singe char Read(1)'s, which will obviously abort when you want it too.

After doing some testing...

mscorlib.dll!System.IO.__ConsoleStream::ReadFileNative(__int32 hFile = 3, unsigned char[] bytes = {Length=256}, __int32 offset = 0, __int32 count = 256, __int32 mustBeZero = 0, __int32 hr = 0) + 0xa4 bytes

Is the lowest section of the call stack during a read to Console.ReadLine(). Im guessing this must be unmanaged (ReadFileNative). Native hardly sounds part of the common runtime, but implementation specfic (though again, speculation).

[queball]

Originally posted by Raging.Retard
bar creating your own ReadLine() method using standard singe char Read(1)'s, which will obviously abort when you want it too.

No.. reading a single char will still block. An alternative would be to use asynchronous I/O. My question would be why it matters - I'd use a seperate thread for managing the console if I wanted to kill threads that might be in reading routines.

As an aside this is similar to SysV read() semantics versus BSD as described in "Worse is Better". Making reads handle aborts properly would complicate the implementation when it's easier to complicate the interface.

[W]

Originally posted by queball
My question would be why it matters - I'd use a seperate thread for managing the console if I wanted to kill threads that might be in reading routines.

That's exactly what I'm doing; the problem is not that it's not isolated in a thread without any cleanup necesarry, the problem is that I still can't kill even when it is...

And it's not like there aren't hundreds of interupts firing off every second anyway; timers for animations and sounds, the mouse might be moving, data arriving at the network interface etc etc. why can't there be a Console.Cleanup() or simply a Console.Reader destructor that can be called while .ReadLine() is interupted, and then simply remove the thread and any reference to it?

[queball]

Originally posted by W
That's exactly what I'm doing; the problem is not that it's not isolated in a thread without any cleanup necesarry, the problem is that I still can't kill even when it is...

And it's not like there aren't hundreds of interupts firing off every second anyway; timers for animations and sounds, the mouse might be moving, data arriving at the network interface etc etc. why can't there be a Console.Cleanup() or simply a Console.Reader destructor that can be called while .ReadLine() is interupted, and then simply remove the thread and any reference to it?

What I don't understand is, if you have a thread just for Console.ReadLine() and it's a zombie, why does it matter? You don't mind if the line read gets lost, you can do calculations somewhere else, and your app will end if the I/O slave thread has its IsBackground set to true (on mono at least).

It's more complicated to manage closing as well as reading bytes. That's the only explanation I can think of.

[W]

Originally posted by queball
What I don't understand is, if you have a thread just for Console.ReadLine() and it's a zombie, why does it matter? You don't mind if the line read gets lost, you can do calculations somewhere else, and your app will end if the I/O slave thread has its IsBackground set to true (on mono at least).

It's more complicated to manage closing as well as reading bytes. That's the only explanation I can think of.

It should, shouldn't it? But when the parent thread exits (all other threads are daemons), it's still there.

The last thing the parent thread does is write out the ThreadState of the last thread, which is always "Background, AbortRequested"...

[queball]

What CLI are you using? Does Console.In.Close() work? (it doesn't on mono, but everything else does)

[W]

Originally posted by queball
What CLI are you using? Does Console.In.Close() work? (it doesn't on mono, but everything else does)

CLI?
And no, closing the stream doesn't work either, I get an exception with the text "Stream does not support writing"

[queball]

Like Microsoft .NET Framework 1.0 or 1.1, or Rotor, I just thought it might be relelvant. Sounds like a runtime bug to me.