share: concurrency handling, easy updates#20870
Conversation
|
@aisle-analyzer augment review |
🔒 Aisle Security AnalysisWe found 1 potential security issue(s) in this PR:
See details in the comment below. Analyzed PR: #20870 at commit Last updated on: 2026-03-09T22:34:54Z |
🤖 Augment PR SummarySummary: This PR reworks share-handle concurrency tracking to avoid relying on a volatile “dirty” counter and to make share attachment/detachment from easy handles safer. Changes:
Technical Notes: The new 🤖 Was this summary useful? React with 👍 or 👎 |
![augmentcode[bot]](https://avatars.githubusercontent.com/in/1027498?s=60&v=4){kind=small}
![aisle-research-bot[bot]](https://avatars.githubusercontent.com/in/1901761?s=60&v=4){kind=small}
|
@vszakats I change
|
|
Because I merged some of your older PRs first, this now needs some merge conflicts sorted out. |
Replace the `volatile int dirty` with a reference counter protected by a mutex when available. Solve the problem of when to call application's lock function by adding a volatile flag that indicates a share has been added to easy handles in its lifetime. That flag ever goes from FALSE to TRUE, so volatile might work (in the absence of a mutex). (The problem is that the lock/unlock functions need 2-3 `curl_share_setopt()` invocations to become usable and there is no way of telling if the third will ever happen. Calling the lock function before the 3rd setopt may crash the application.) When removing a share from an easy handle (or replacing it with another share), detach the easy connection on a share with a connection pool. When cleaning up a share, allow this even if it is still used in easy handles. It will be destroyed when the reference count drops to 0.
share: use `share_in_use` for checking cleanup deny configure/cmake defines: Disentangle mutex/threads availability from threaded resolver. We want to use mutex also when other resolvers are configured. This means: - USE_THREADS_POSIX and USE_THREADS_WIN32 gone - replaced with HAVE_THREADS_POSIX and HAVE_THREADS_WIN32 - introduce USE_RESOLV_THREADED and USE_RESOLV_ARES - introduce curl_setup.h defines - USE_MUTEX when pthread/win32 mutex should be used - USE_THREADS when threads are used - remove CURLRES_ARES and CURLRES_THREADED Will probably break in CI for cmake builds, we'll see.
|
rebased |
3 participants
curl share:
Replace the
volatile int dirtywith a reference counter protected by a mutex when available.Solve the problem of when to call application's lock function by adding a volatile flag that indicates a share has been added to easy handles in its lifetime. That flag ever goes from FALSE to TRUE, so volatile might work (in the absence of a mutex).
(The problem is that the lock/unlock functions need 2-3
curl_share_setopt()invocations to become usable and there is no way of telling if the third will ever happen. Calling the lock function before the 3rd setopt may crash the application.)When removing a share from an easy handle (or replacing it with another share), detach the easy connection on a share with a connection pool.
configure/cmake:
Disentangle mutex/threads availability from threaded resolver. We want to use mutex also when other resolvers are configured. This means:
- USE_MUTEX when pthread/win32 mutex should be used
- USE_THREADS when threads are used