{"author":"Stefan Eissing","author_email":"stefan@eissing.org","author_time":1755697700,"commit_time":1755761209,"committer":"Daniel Stenberg","committer_email":"daniel@haxx.se","hash":"88fc6c491f043ed184ea2cf1a17b651427fbbbf5","message":"threaded-resolver: fix shutdown\n\nChanged strategy to start up and terminate resolver thread.\n\nWhen starting up:\n\nStart the thread with mutex acquired, wait for signal from thread that\nit started and has incremented the ref counter. Thread set\npthread_cancel() to disabled before that and only enables cancelling\nduring resolving itself. This assure that the ref counter is correct and\nthe unlinking of the resolve context always happens.\n\nWhen shutting down resolving:\n\nIf ref counting shows thread has finished, join it, free everything. If\nthread has not finished, try pthread_cancel() (non Windows), but keep\nthe thread handle around.\n\nWhen destroying resolving:\n\nShutdown first, then, if the thread is still there and 'quick_exit' is\nnot set, join it and free everything. This might occur a delay if\ngetaddrinfo() hangs and cannot be interrupted by pthread_cancel().\n\nDestroying resolving happens when another resolve is started on an\neasy handle or when the easy handle is closed.\n\nAdd test795 to check that connect timeout triggers correctly\nwhen resolving is delayed. Add debug env var `CURL_DNS_DELAY_MS`\nto simulate delays in resolving.\n\nFix test1557 to set `quick_exit` and use `xxx.invalid` as domain\ninstead of `nothing` that was leading to hangers in CI.\n\nCloses #18263\n","parents":["f3488ee3a340dc56a23f28f9000a3ec2619fcb63"],"tree_hash":"f154d83831d8ed4d994648401c5c8b12e20c09a1"}