Sospensione di tutti i thread nel processo corrente in fase di esecuzione

Question

Nella mia app ho un bug che sembra mostrare il suo volto solo quando sospendo l'app nel debugger per alcuni minuti. Sospetto che ciò sia dovuto a una libreria di rete di terze parti che sto usando con un thread heartbeat, che viene disconnesso quando non può eseguire il ping del server mentre il thread heartbeat è in pausa.

Sto provando a scrivere un'app di test case per verificare che questa sia la causa del bug. Per fare ciò, ho bisogno di un modo per mettere in pausa tutti i thread nell'app (che in seguito mi limiterò a mettere in pausa solo il thread che sospetto possa essere il thread heartbeat) per simulare l'interruzione dell'app nel debugger.

Qualcuno sa come fare? È persino possibile che un thread faccia dormire un altro?

Grazie, Alex

UPDATE:

ho finito per decidere che non ho davvero bisogno di un app per fare questo per me, visto che il punto era solo per verificare che una pausa nel debugger stava causando la disconnessione. Quindi, ecco quello che ho fatto ... (I modi più semplici sono spesso le migliori ... o per lo meno la più semplice ...)

private static void Main(string[] args) 
    { 
     IPubSubAdapter adapter = BuildAdapter(); 
     bool waitingForMessage; 
     adapter.Subscribe(_topic, message => waitingForMessage = false, DestinationType.Topic); 
     Stopwatch timePaused = new Stopwatch(); 
     while (adapter.IsConnected) 
     { 
      Console.WriteLine("Adapter is still connected"); 
      waitingForMessage = true; 
      adapter.Publish(_topic, "testmessage", DestinationType.Topic); 
      while (waitingForMessage) 
      { 
       Thread.Sleep(100); 
      } 
      timePaused.Reset(); 
      timePaused.Start(); 
      Debugger.Break(); 
      timePaused.Stop(); 
      Console.WriteLine("Paused for " + timePaused.ElapsedMilliseconds + "ms."); 
      Thread.Sleep(5000); // Give it a chance to realise it's disconnected. 
     } 
     Console.WriteLine("Adapter is disconnected!"); 
     Console.ReadLine(); 
    } 

E l'output:

Adapter is still connected 
Paused for 10725ms. 
Adapter is still connected 
Paused for 13298ms. 
Adapter is still connected 
Paused for 32005ms. 
Adapter is still connected 
Paused for 59268ms. 
Adapter is disconnected! 

Answer 1

È possibile utilizzare questo per identificare rapidamente i fili del vostro processo:

using System.Diagnostics; 

ProcessThreadCollection threads = Process.GetCurrentProcess().Threads; 

Poi si può use kernel32.dll with P/Invoke di fare tutto ciò che ti serve con quei fili. Utilizzare OpenThread per ottenere un handle per il thread desiderato e quindi sospenderlo con SuspendThread utilizzando quell'handle.

Ecco la dichiarazione P/Invoke per i due metodi:

[DllImport("kernel32.dll")] 
static extern IntPtr OpenThread(uint dwDesiredAccess, bool bInheritHandle, uint dwThreadId); 

[DllImport("kernel32.dll")] 
static extern uint SuspendThread(IntPtr hThread); 

Answer 2

Si può chiamare l'Thread.Suspend poi Thread.Resume metodi, ma questi sono deprecata e non è recommneded usarli.

Ma è possibile fare quanto segue: Avere una bandiera booleana che quando si imposta si mette il filo in un grande sonno. OR Meglio usare ManualResetEvent.

Answer 3

È possibile sospendere i thread chiamando Thread.Suspend. La documentazione dà grande "NON FARE QUESTO!" avvertimenti sulla deprecazione, ma penso che il tuo sia un caso d'uso valido.

Jon Skeet pensa you can't enumerate managed threads nel normale codice C#, sebbene indichi una possibile soluzione.

Answer 4

Suppongo che tu non abbia intenzione di mettere in pausa tutti i i thread nell'applicazione, altrimenti non ci sarà nulla in esecuzione per annullarli. O mi sono perso qualcosa?

Un suggerimento: prova a dare nomi a tutti i thread che crei. Qualsiasi thread senza un nome o che non corrisponde alla tua convenzione di denominazione, deve essere stato creato da un componente di terze parti. Questo potrebbe portarti alla causa principale più velocemente senza dover mettere in pausa molti thread.

Answer 5

Dal mio pov non sembra giusto.

• Che tipo di test stai scrivendo? Se si sta parlando di unit test, questo non è un caso di test unitario - sembra più un test di integrazione
• Si consiglia di isolare le chiamate API in una classe e quindi utilizzare l'iniezione dependendcy in modo da poter eseguire il test senza la libreria di terze parti con deride/stub e può anche provocare/testare un'eccezione sollevata dalla libreria di terze parti