Builder curl-ares-solaris11-sparc Build #4264

Results:

Build successful

SourceStamp:

BuildSlave:

Reason:

The SingleBranchScheduler scheduler named 'schedule-curl-ares-solaris11-sparc' triggered this build

Steps and Logfiles:

1. git update ( 1 hrs, 2 mins, 48 secs )
   1. stdio
2. Runtest './tests/testcurl.pl --nogitpull ...' ( 1 hrs, 14 mins, 52 secs )
   1. stdio
   2. resultlog
3. Mail result 'cat resultlog ...' ( 8 secs )
   1. stdio

Build Properties:

Forced Build Properties:

Responsible Users:

1. Stefan Eissing

   stefanohnoyoudont@eissing.org

Timing:

All Changes:

:

1. Change #241080

   Category	curl
   Changed by	Stefan Eissing <stefanohnoyoudont@eissing.org>
   Changed at	Mon 28 Jul 2025 22:57:42
   Repository	https://github.com/curl/curl.git
   Project	curl
   Branch	master
   Revision	85e18a5b9a60109d139e702c9c1028fa6ff4366e

   Comments

   multi: process pending, one by one
   Before curl 8.14.0, when pending was a list, `process_pending_handles()`
   move a single transfer to processing. In 8.14.0 we changed that to move
   all pending transfers to processing. This lead to unwanted performance
   drops as reported in #18017.
   
   Restore the old behaviour.
   
   While the old behviour is better, the overall handling of "pending"
   transfers is not optimal, since we do not keep track of the "condition"
   a pending transfer is waiting on. This means, when moving a single,
   pending transfer, we might move one that still cannot be processed while
   another that could is kept pending.
   
   Since we trigger `process_pending_handles()` from various changes, the
   stalled pending will eventually make it to the processing queue, but
   this is not optimal.
   
   Fixes #18017
   Reported-by: rm-rmonaghan on github
   Closes #18056

   Changed files

   • lib/multi.c