TAPI TSP Service Provider - Problem mit MultiThreading
-
Hallo Leute,
falls das im falschen Forum gelandet ist bitte verschieben
Zu meiner Ausgangslage:
Ich schreibe aktuell einen eigenen TSP.
Hierfür verwende ich Visual Studio 2015.
Das Testsystem ist ein frisch installiertes Windows 7 Pro.Mein Problem ist folgendes:
Ich muss von einem anderen Programm (in C# geschrieben) aus im TSP Events auslösen (z.B. CallState Änderungen etc.).Hierfür hätte ich im TSP einen Socket Server erstellt, worauf ich mich mit dem C# Programm verbinden kann.
Das funktioniert theoretisch auch, aber da der Socket den gesamten TSP blockiert, hängt natürlich alles.Folglich hätte ich jetzt den Socket Server in einen eigenen Thread im TSP ausgelagert.
Hierfür habe ich sowohl std::thread, als auch CreateThread getestet.Jedoch tritt jedes mal beim Installieren/Starten des TSP das gleiche Problem auf, und zwar hängt sich der komplette Telefonie-Dienst im Windows auf und ich muss alles neu starten.
Im Eventlog wirft die svchost.exe (die die TSP geladen hat) entweder den Fehler 0x40000015, oder den Fehler 0xc0000005 aus. Beides nicht sehr aussagekräftig.Wenn ich den gleichen Code in einem Konsolen-Testprojekt ausführe, funktionert alles ganz normal.
Kann es sein, das TSPs nicht MultiThreaded sein dürfen?
Ansonsten habe ich noch versucht die TSP in ein anderes C# Programm einzubinden und dann eine exportiere Funktion (z.B. void Test()) aufzurufen.
Daraufhin stürzt auch der gesamte Telefoniedienst ab.Jemand eine Idee und kann mir weiterhelfen?
Danke, für jeden, der das alles bis zum Ende gelesen hatGruß,
Matthias
-
1. Natürlich dürfen TSP Multithreading sein.Ich habe schon mehrere TSPs geschrieben, das ist kein Problem und fast immer notwendig...
2. Du solltest aber keine threads starten aus Deinem DllMain! Das ist ganz bööööse....
3. Du kannst doch debuggen. Starte Dein VS als Admin. Besorge Dir die PID des SVCHosts und attache den Debugger.
4. Noch besser: Debugge remote in einer virtuellen Maschine...
5. Was Deine Crashes angeht sieht es eher nach handfesten Programmierfehlern und kaputten Heap aus.Tipp:
Ich rate Dir dringendst um TSPs zu entwicklen, den Dienst autark zu starten.
Siehe "How can I run TAPISRV exclusively in a svchost process ?"
http://www.i-b-a-m.de/Andreas_Marschall's_TAPI_and_TSPI_FAQ.htm#_Q:_How_can_6
Dann fliegen Dir nicht gleich 1000 andere Dienste um die Ohren.Für mich hier eher die kritischen Fragen:
Wo bitte läuft die EXE?
Wer startet die?
Welcher User-Kontext ist das?
TSPs werden einmal je Maschine gestartet. Mach Dir Gedanken was in einer Terminal-Server Umgebung passieren kann...PS: Ich persönlich hasse es mit TCP/IP auf einer lokalen Maschine Interprozesskommunikation zu betreiben. Aber jeder wie er mag.
-
Super, vielen Dank für die schnelle und hilfreiche Antwort
Nachdem ich den Thread jetzt erst in der ProviderInit-Funktion starte (was mir auch ausreicht), läuft alles wie erhofft.
Ich hab leider seit mehreren Jahren nichts mehr mit C bzw. C++ zu tun gehabt, deswegen ist vieles wieder Neu für mich.Die Tipps und der Link haben mir auch sehr weitergeholfen.
An den VS Remote Debuggger hab ich gar nicht gedacht -.-Zu den Fragen am Ende:
Die EXE läuft auf einem komplett anderen Server (auf dem eine Software Telefonanlage läuft).
Dort läuft diese aktuell noch (zum Testen) als Konsolenanwendung unter dem Administrator.
Für die Kommunikation direkt auf dem gleichen System hätte ich auch keine TCP-Sockets verwendet.Gibts es große Fallstricke bei Terminalservern?
Eventuell sonst noch Tipps bzw. Probleme über die ich stolpern könnte?
Ich weiß natürlich, das so ein TSP Projekt nicht gerade einfach istDanke.
-
ProviderInit ist in jedem Fall der richtige Punkt. In DllMain Initialisierungen zu machen ist und bleibt auf sehr wenige Dinge beschränkt.
Ein no go ist es Threads zu starten oder in DllMain andere DLLs zu laden...Wenn die Anwendung auf einem anderen Server läuft ist alles OK.
Da sehe ich auch keine Probleme unter Terminalserver.Meine Befürchtung war eher, das die EXE von einem Benutzer gestartet wird auf dieser Maschine und der TSP, dann mit dieser "User-EXE" Kontakt aufnehmen soll und diese steuert.
Bei einem Terminalserver würde diese "User-EXE" ja dann mehrfach laufen. Der TSP, der nur einmal läuft müsste dann wissen welche "User-EXE" er anspricht.
Das geht, aber ist ziemlich kompliziert.
Und ja: TSP Programmierung ist nicht einfach. Und vor allem zeichnen sich existierende TSPs sehr oft genug durch eine extrem schlechte Programmierung aus. So meine Erfahrung.
Ich entwickle eigentlich mehr Software, die unterschiedlichste TSPs nutzt.
-
OK dann bin ich beruhigt.
Danke nochmal und der Thread kann eigentlich als gelöst geschlossen werden.
-
So was gibt's hier nicht...
