Debugen mit Hintergrund Thread / Probleme mit Serieller Kummunikation

Hallo ich habe schon seit einer ewigkeit das Problem das ich bei jedem Breakpoint meinen Hintergrund Thread quasi "erschlage"

Weil die Communikation mit meiner Hardware immer irgendwo im Thread stehen bleibt und dann (was auch verständlich ist) nicht mehr Funktioniert.
Die Option im beim Debugger nicht alle Processe zu stoppen funktioniert leider auch nicht.
Wobei ich nicht verstehe warum er nicht bis zu meinem Event / Invoke weiterläuft und dann da stehen bleibt weil ich den GUI Thread ja angehalten habe.

Weiß jemand ob es eine Möglichkeit gibt das ganze zu umgehen (so das bei einem Breakpoint im GUI Thread der BackgroundWorker nicht irgendwo stehen bleibt)

oder muss man damit leben?

Hallo Console32,

wenn du Control.Invoke verwendest, wartet der Worker-Thread auf die Beendigung der Aktion im GUI-Thread. Wenn sich diese wegen eines Breakpoints im GUI-Thread verzögert, wartet also auch der Worker entsprechend lange. Du solltest prüfen, ob im konkreten Fall auch Control.BeginInvoke in Frage kommt, weil der Worker gar nicht aufs GUI wartet.

Dass ist allerdings eher eine Frage von [FAQ] Controls von Thread aktualisieren lassen (Control.Invoke/Dispatcher.Invoke) als vom Debugging. Ich wüsste auch nicht, wie man dem Debugger sagen sollte, "hey, ich habe hier einen Breakpoint im GUI-Thread und der Worker wartet auf den GUI-Thread, lassen den Worker bitte trotzdem weiterlaufen". Das würde ja die Semantik des Programms grundsätzlich ändern und könnte auch zu Synchronisierungsfehlern führen.

Wenn die Stricke beim Debugging reißen, kann (muss) man auf Logging ausweichen.

herbivore

Hallo herbivore,

Ob mein BackgroundWorker bei dem Invoke nun stehen bleibt oder mit BeginInvoke nicht ist nicht das Problem, das Problem ist das der Worker in etwa so aussieht:

while
{
   Expensive BackgroundWork
   Communication
   Cheap GUI Events
}

Mal von der Standard Option "Break all Processes" ausgegangen.

Nun ist das Problem das wenn ich im GUI-Thread einen Breakpoint setzte dann wird der BackgroundWorker sehr wahrscheinlich in einem Kritischen Bereich der Kommunikation stehen bleibt.

Wenn ich dann weiter mache geht der Background Worker Flöten weil meine Hardware die Kommunikation abbricht.

nun wäre es Logisch die Option "Break all Processes" auszuschalten (Um zu erzwingen das der Worker an einem meiner Invokes stehen bleibt). Das hilft leider überhaupt nicht und ich hab keine ahnung wieso :S

Hallo Console32,

wenn der Worker schon während "Communication" stehen bleibt, dann scheint schon dort ein GUI-Zugriff stattzufinden. Wobei GUI-Zugriff sehr weitgefasst zu verstehen ist und jede Behandlung einer Windows Nachricht im Main-Thread darunter fällt.

Ansonsten habe ich ja schon eine Alternative zum Debugger genannt.

herbivore

Hallo herbivore,

soweit ich weiß mache ich nichts derartiges, wäre ja ein gröberes Problem wenn mein Backgroundworker irgendwo Window Messages rumfeuert.

eigentlich kann das ganze nicht sein da die Klasse die für meine Kommunikation verantowrtlich ist nichts von meinem gui Thread weiß. Das ganze läuft nur über diese Events und die sind Alle am ende eines Zyklus meiner "Arbeiter" Schleife.

Ich werd trotzdem mal sehen ob ich etwas ähnliches finde

Bei externen Komponenten solltest Du Dich mit Mocking vertraut machen und auch ueberlegen, dass Du dann damit das Verhalten der externen Komponenten nachstellen kannst.
FakeItEasy ist da mein aktueller Favorit.