Interest in implementing CURLINFO_PAUSE_STATE (TODO / #2588) #22261
vigneshwarrvenkat
started this conversation in
Ideas
Replies: 3 comments
|
You're welcome to make a PR for this. Note: when you say "from another thread" that use of an easy handle in several threads is not allowed. But a callback might be interested in querying this. For your implementation to pass CI, there are many checks on documentation, symbols and versions to be declared, etc. The actual code might be the easier part. We're happy to answer any questions you might have. |
0 replies
|
@icing I'll open a PR shortly with the documentation and tests included. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Hi,
I'm interested in contributing to curl and wanted to ask about a feature listed in docs/TODO.md before I start working on it.
Background
Issue #2588 requested a way to read the pause state of an easy handle. It was closed as a feature request, with the idea tracked in TODO.md as CURLINFO_PAUSE_STATE instead. In that thread, Daniel suggested using curl_easy_getinfo() rather than adding a separate API function.
Proposal (high level)
Add a new curl_easy_getinfo() option, something like:
CURLINFO_PAUSE_STATE
that returns the current pause state for both directions, using the existing CURLPAUSE_RECV and CURLPAUSE_SEND bitmask values (consistent with curl_easy_pause()).
The use case is applications that pause/unpause transfers from another thread or callback and need to know the current state before acting.
Questions
Is this still something the project wants, or has the direction changed since it was added to TODO?
Would CURLINFO_PAUSE_STATE be an acceptable name, or is there a preferred alternative?
Are there any design constraints I should follow upfront (e.g. behavior when no connection is active, interaction with callback-driven pauses)?
May I go ahead and start on an implementation and open a PR, or would you prefer further discussion on the mailing list first?
I'm happy to follow whatever process you recommend for new libcurl API additions.
All reactions