Network und Window

[ParkL]

Hallo,

ich habe eine Frage, wie ihr etwas implementieren würdet.

Ich möchte ein Programm schreiben, das gleichzeitig Window Events fängt und einen Server laufen lässt.

Ich seh da jetzt prinzipiell zwei Möglichkeiten.

1. Ich lasse die Window-Events im HauptThread laufen und mache einen eigenen Thread für die Server Events auf.

Vorteil: Ich kann WaitWindowEvent benutzen, d.h. dieser Thread haut schonmal nicht so auf die Performance.
Nachteil: In meinem Server Thread darf ich keine Strings beutzen, weil PB-Strings ja nicht Thread-Safe sind.

2. Möglichkeit: Ich lasse beide Events in einem Thread in einer Schleife laufen.
Vorteil: Ich kann im Prinzip machen was ich will.
Nachteil: Ich muß jedesmal windowevent beim schleifendurchlauf abfragen und vor allem ständig irgendwelche delays einbauen.

Bitte gebt mir mal nen Tipp wie ihr das lösen würdet.

Gruß

ParkL

[FloHimself]

Möglichkeit 2 würde ich niemals benutzen. Die Windows event loop für andere Zwecke zu missbrauchen ist einfach schlechter Programmierstil.

Ich würde Möglichkeit 1 bevorzugen. Die Thread- / String- Problematik ist halb so wild. Stichwort Critical Section und Mutex.

[Team100]

..... wir haben einige Zeit über dieses Thema nachgedacht,
weil unsere Programme bei Kunden und weit verstreut
eingesetzt werden. Probleme können da leicht existenz-
gefährdend werden......

Da einerseits in den Unterlagen auf die Thread-String-Problematik
hingewiesen wird, andererseits Beiträge in diesem Forum auch
gewisse Unsicherheiten vermuten lassen, haben wir uns aus
Sicherheitsgründen doch für die Variante 2 entschieden.

Das mag elegant sein oder nicht, die Verwendung einer
einzigen Schleife hat durchaus auch Vorteile:

- die Sicherheit im Stringbereich
- einfacheres Nachvollziehen bei zeitabhängigen Fehlern
- unabhängiges Entwickeln der einzelnen Schleifenelemente
(Network, Window-Events, Timers etc), auch durch mehrere Mitarbeiter
- unkritisches Nachbessern des Programmes in der
Zukunft durch neu hinzugekommene Mitarbeiter.

Grundsätzlich werden nur Schleifenprozeduren in die
Hauptschleife eingeswitched, die gerade benötigt werden.

Das Problem mit dem Delay ist auch nicht wirklich eines:
Wir verwenden ein dynamisches Delay, das sich dem entsprechenden
Leistungsbedarf des Programmes anpaßt.

Bisher hatten wir wohl gute Erfolge mit dem Konzept:
über 100 Installationen bundesweit unter unterschiedlichen
Netzverhältnissen, kein einziger kritischer
Abbruch oder Hänger im Log zu sehen seit der Installation vor 3 Monaten,
beste Kundenakzeptanz...

Eckdaten: Das Programm hat etwa 17000 Codezeilen,
15 Windows, ca 200 Gadgets, der durchschnittliche Netzwerkstraffic ist
etwa 270 MB /Tag , keine LinkedLists, nur Arrays.

Eigentlich läuft das Programm zu 100% problemlos....

Wenn ich etwas privat programmieren würde, wäre sicher
Variante 1 die erste Wahl, auch um mehr Erfahrungen mit den Threads
und Strings zu sammeln, auch ist das Arbeiten mit Threads
ungleich interessanter....

Cu von Team100

[Lars]

Threads sind hier imho nicht wirklich nötig, dafür geht das mit Möglichkeit 2
viel zu bequem.

Wo ist denn das Problem bei folgendem, schematischem Code?

Code: Alles auswählen

Repeat
  WinEvent = WindowEvent()
  NetEvent = NetworkServerEvent()
  
  ;whatever
  
  If WinEvent = 0 And NetEvent = 0
    Delay(10)
  EndIf
Until Abbruchbedingung

[bluejoke]

Falls z.B. nur nach dem drücken eine Buttons auf ein Netzwerkevent geachtet werden muss kann man ja optional dafür WaitWindowEvent() nehmen.

Einfach den Status (ist Network aktiv oder nicht) in einer If-Abfrage abfragen (mir fällt kein anderes wort dazu ein) und je nachdem WindowEvent() oder WaitWindowEvent verwenden.

[FloHimself]

@Lars
Es gibt kein Problem. Probleme wird es aber geben, wenn du komplexere, zeitraubende Berechnungen durchführen möchtest. Fenster, Netzwerk, Visualisierung von Daten, Report in Datei schreiben, etc, da machen Threads durchaus Sinn.

@Team100
Die Warnung in der Hilfe ist ein Hinweis darauf, das PureBasic von sich aus nicht Thread-Safe ist. Alle hier haben Angst vor Threads. Ich kann es nicht nachvollziehen und setze sie bisher ohne Probleme ein. Du bringst tolle Zahlen, aber deine vorgebrachten "Vorteile" sehe ich nicht als solche. Dein Posting liest sich, als wäre der Erfolg deiner Software von der Entscheidung gegen Threads abhängig. Der Erfolg einer Software hängt im Allgemeinen von ganz anderen Faktoren ab. Die Stabilität des Programms ebenso.

[Team100]

@Flo
Ich habe durchaus nichts gegen die Verwendung von Threads, und
verstehe Deinen Standpunkt, insbesonders Du gute Erfahrungen
gemacht hast.

Möglichkeit 2 würde ich niemals benutzen.
Die Windows event loop für andere Zwecke zu missbrauchen ist einfach
schlechter Programmierstil.

Dieser Aussage kann ich aber nicht zustimmen. Das angeführte Beispiel
soll aufzeigen, daß es eben auch ohne Threads in komplexeren Abläufen
funktionieren kann, als Gegengewicht zu deiner Aussage.

Mehrere Meinungen zu einem Thema sind für die interessierten User
immer hilfreich.

Wie schon gesagt, ich bin nicht gegen Threads, aber bei unseren
Programmen für Anwendungen im Geldverkehr bleiben
sie nunmal grundsätzlich draußen, ganz gleich ob sie ein tatsächliches
Risiko sind oder nur ein hochgespieltes.

Cu von Team100

[FloHimself]

@Flo
Ich habe durchaus nichts gegen die Verwendung von Threads, und
verstehe Deinen Standpunkt, insbesonders Du gute Erfahrungen
gemacht hast.

Ich habe auch nichts gegen Deinen Standpunkt! Ich finde es nur grausig, das Threads hier immer wieder ins schlechte Licht gerückt werden. Threads in PureBasic sind nicht anders als Threads in C mit WINAPI.

Möglichkeit 2 würde ich niemals benutzen.
Die Windows event loop für andere Zwecke zu missbrauchen ist einfach
schlechter Programmierstil.

Dieser Aussage kann ich aber nicht zustimmen. Das angeführte Beispiel
soll aufzeigen, daß es eben auch ohne Threads in komplexeren Abläufen
funktionieren kann, als Gegengewicht zu deiner Aussage.

Natürlich geht es anders. Ich orientiere mich hier einfach an Charles Petzold:

Der primäre Thread kümmert sich um alle Fenster des Programms - legt sie an, enthält die Window-Prozeduren, behandelt die Nachrichten etc. -, die sekundären Threads erledigen längere Arbeiten asynchron im Hintergrund.

Dazu kommt die Zentelsekundenregel.

[ParkL]

Also ich würde halt auch ab liebsten Möglichkeit 1 benutzen. Ich habe keine "Angst" vor Threads, ganz im Gegentum. Ein Bekannter hat nur mit String Manipulationen in Threads in PB sehr schlechte Erfahrungen gemacht, weil die Ergebnisse teilweise unvorhersehbar waren. Ich glaub irgendwo hier im Forum gibt's dazu auch ein lustiges Beispiel.

PB verwendet wohl intern nur 1 String Pointer (korrigiert mich wenn ich da falsch liege), was in einem 1 Thread Programm kein Problem ist, bei mehreren Threads aber schon.

Ein Server sollte in einem eigenen Prozess laufen, das ist sauberer.

Man könnte schon sowas proggen:

Code: Alles auswählen

repeat
  if svrrunning
    wEvt = windowevent()
    sEvt = networkserverevent()
     HandleServerEvt(sEvt)
     HandleWindowEvt(wEvt)
      delay(10)
  else
    wEvt= waitwindowevent()
     HandleWindowEvt(wEvt)
  endif
until quit

aber das ganze ist mir irgendwie zu "unrund" (ist wohl mehr nen gefühl )

Eine andere Möglichkeit wär's natürlich komplett auf PB's concat etc. funktionen zu verzichten und das ganze im Speicher direkt zu erledigen, aber dann kann ich's irgendwie auch direkt in ner "Tiefsprache" schreiben. Habe keine Lust, mir eine eigene Concat Funktion zu proggen.

Mutex: Wie erklär ich's dem Compiler ? Es gibt kein "synchronized" in PB wie's das in Java gibt. Ich kann nicht

Ich danke euch für Eure Gedanken zum Thema ... Ich werd erstmal probieren, so zu schreiben, wie ich's in Java oder C implementieren würde. Wenn das nicht funktioniert, werd ich wohl eine der vorhergenannten Sprachen verwenden müssen.

[dige]

Das Thema Thread-Syncronisation mit Critical Sections wird auch gerade
aktuell im englischen Forum behandelt.

http://purebasic.myforums.net/viewtopic.php?t=13712

Dort gibt es von PolyVector 2 gute Code-Beispiele.


cya dige