Boost Asio io_service Destruktor hängt unter OS X

8

Ich habe ein Problem mit Boost Asio unter OS X, wo der io_service-Destruktor manchmal unbegrenzt hängt. Ich habe einen relativ einfachen Reprofall:

%Vor%

Im Grunde werden nur zwei Handler in die Warteschlange gestellt, von denen einer einen Timer programmiert und der andere nur einen anderen Handler posten kann. Manchmal führt dieses einfache Programm dazu, dass der io_service -Destruktor auf unbestimmte Zeit hängen bleibt, insbesondere in% des_de_destructor% co_de während der pipe_select_interrupter -Zerstörung. Dies blockiert im Systemaufruf kqueue_reactor auf dem Pipe-Lesedeskriptor.

Um den Fehler auszulösen, rufe ich das Programm in einer Schleife mit einem Shell-Skript auf (aber es ist auch möglich, im obigen Beispiel eine Schleife auszulösen):

%Vor%

Ich kann nicht mehr reproduzieren, wenn ich:

  • Entfernen Sie den Aufruf von close() am Anfang (!). Edit: Dies scheint nur zu gelten, wenn ich mit dem Skript laufe. Wenn ich stattdessen eine Schleife im Programm selbst hinzufüge, kann ich sie auch ohne diesen Aufruf nach dem Kommentar von Ruslo wiedergeben.
  • Entfernen Sie den Aufruf von gmtime_r() für den Timer im Handler oder verschieben Sie das Timer-Setup außerhalb des Handlers.
  • Entfernen Sie die async_wait() im zweiten Handler.
  • Verringern Sie die Anzahl der Threads.
  • Platziere einen Mutex in post() . Diese Funktion wird von kqueue_reactor::interrupt() und async_wait() aufgerufen und ruft post() mit dem Lesedeskriptor auf, der dann nicht geschlossen werden kann.

Tue ich etwas falsches im obigen Code?

Ich laufe auf OS X 10.8.5 mit Boost 1.54 und kompiliere mit kevent() . Ich kann auch mit Boost Asio von Boost 1.55 (mit dem Rest von Boost 1.54 wie es ist) reproduzieren.

Bearbeiten: Ich kann auch auf OS X 10.9.1 (mit der gleichen ausführbaren Datei) reproduzieren.

    
villintehaspam 17.02.2014, 17:39
quelle

1 Antwort

1

Die Lösung dafür wurde Asio in der Masterfiliale am 29. April 2014 übergeben

  

Fix gelegentliche close () Systemaufruf hängt auf MacOS.

     

Wiederholte erneute Registrierung von Filtern für kqueue Ereignisse scheint sich wie zu verhalten   obwohl es auf MacOS eine Art "Leck" gibt, das in einer Aussetzung endet   close () Systemaufruf und ein unkalkulierbarer Prozess. Um dies zu vermeiden, werden wir   Registrieren eines Kqueue-Ereignisses eines Deskriptors nur einmal, d.h. wenn das   Deskriptor wird zuerst erstellt.

    
sehe 08.01.2015, 09:35
quelle