Ich habe viel Zeit investiert, um zu untersuchen, warum Multithread-basierte libcurl-Anwendungen unter Linux abstürzen. Ich habe in Foren gesehen, dass ich CURLOPT_NOSIGNAL verwenden muss, um dieses Problem zu umgehen. Ok, keine Probleme, aber gibt es irgendwelche Informationen, welche Nebenwirkungen kann es erzeugen? Wenn CURLOPT_NOSIGNAL = 0 fehlerhaft ist, warum benötigt libcurl diese Option überhaupt, wenn sogar mobile Geräte Multicore-Prozessoren haben, und deshalb verwenden viele Anwendungen mehrere Threads, um diese Hardware-Multitasking-Unterstützung zu nutzen?
Standardmäßig verwendet die DNS-Auflösung Signale, um die Timeout-Logik zu implementieren, aber dies ist nicht Thread-sicher: Das Signal könnte auf einem anderen Thread als dem ursprünglichen Thread ausgeführt werden, der es gestartet hat.
Wenn libcurl nicht mit Unterstützung für asynchrone DNS erstellt wurde (was Threaded Resolver oder c-ares bedeutet), müssen Sie die Option CURLOPT_NOSIGNAL in Ihrer Multithreadanwendung auf 1 setzen.
Weitere Informationen zu diesem Thema finden Sie hier:
Warum benötigt libcurl diese Option heutzutage?
Hauptsächlich aus Legacy-Gründen, aber auch, weil nicht alle Anwendungen libcurl in einem Multithread-Kontext verwenden.
Dies wird immer noch aktiv diskutiert. Sehen Sie sich diese aktuelle Diskussion an:
libcurl hat keine eigenen Threads, die es schützen muss und es nicht kennt welche Thread-Bibliothek / welches Konzept du verwendest, damit es die Callbacks nicht selbst setzen kann. Dies war das Thema der Diskussion, und es gibt tatsächlich Gültigkeit Gründe zu überdenken, was wir tun können und sollten, aber so ist es war seit immer und immer noch. [...] aber ich bin immer offen für weitere Diskussionen!
Tags und Links c c++ multithreading curl libcurl