> Am 27.08.2023 um 20:35 schrieb Patrick Monnerat via curl-library
> :
>
>
> On 8/27/23 18:01, Daniel Stenberg via curl-library wrote:
>> On Sun, 27 Aug 2023, Henrik Holst via curl-library wrote:
>>
>>> CURL **handles = curl_multi_get_handles(multi);
>>>
>>> where the last position in *hand
On Mon, 28 Aug 2023, Stefan Eissing via curl-library wrote:
CURL **handles = curl_multi_get_handles(multi);
The tricky part is to handle iterations when easy handles are removed and
freed during the iteration. If we save pointers, this can become tedious.
Right, but it has the nice property
> Am 28.08.2023 um 12:41 schrieb Daniel Stenberg :
>
> On Mon, 28 Aug 2023, Stefan Eissing via curl-library wrote:
>
> CURL **handles = curl_multi_get_handles(multi);
>>
>> The tricky part is to handle iterations when easy handles are removed and
>> freed during the iteration. If we save
On Mon, 28 Aug 2023, Stefan Eissing wrote:
Yes, that is why I propose a snapshot (internal, invisible) of the transfer
ids. Then the caller can even free handles during iteration without
headaches.
Ah, of course!
The iterator approach has the plus that it does not end up with the
applicatio
On 8/28/23 12:51, Stefan Eissing via curl-library wrote:
Am 28.08.2023 um 12:41 schrieb Daniel Stenberg :
On Mon, 28 Aug 2023, Stefan Eissing via curl-library wrote:
CURL **handles = curl_multi_get_handles(multi);
The tricky part is to handle iterations when easy handles are removed and f
On Mon, 28 Aug 2023, Patrick Monnerat via curl-library wrote:
I think letting the array update to the caller's responsibility is much
simpler and does not bring much bloat to the calling program.
I made a first draft of a PR for how the array based API could work:
https://github.com/curl/cu
> Am 28.08.2023 um 13:06 schrieb Patrick Monnerat via curl-library
> :
>
>
> On 8/28/23 12:51, Stefan Eissing via curl-library wrote:
>>
>>> Am 28.08.2023 um 12:41 schrieb Daniel Stenberg :
>>>
>>> On Mon, 28 Aug 2023, Stefan Eissing via curl-library wrote:
>>>
>>> CURL **handles = cur
On Mon, 28 Aug 2023, Stefan Eissing via curl-library wrote:
We can declare this out-of-scope. Then the list will work well.
I'm interested to hear others' opinions on prefered API for this functionality
as well. I don't think we need to judge a winner approach just yet.
This can't be merged
Hello,
Is there any documentation / how to on the process I’d need to follow to add a
new option to the tool ?
Particularly the sequence of files / function / macros I’d need to
I’m trying to $subject and I’m having trouble getting the process right.
Specifically I’m working on a new - - warc
On Mon, 28 Aug 2023, Florents Tselai via curl-library wrote:
For reference you could check the last commit here
https://github.com/Florents-Tselai/curl/commit/d6ce0b1a0c619f8df1fb61a2638848d25e2aab75
You have not added code in src/tool_getparam.c:getparameter() that actually
does something wh
On Mon, Aug 28, 2023 at 08:11:14PM +0300, Florents Tselai via curl-library
wrote:
> Is there any documentation / how to on the process I’d need to follow to add a
> new option to the tool ?
> Particularly the sequence of files / function / macros I’d need to
There are lots of documentation in th
> On 28 Aug 2023, at 8:24 PM, Daniel Stenberg wrote:
>
> On Mon, 28 Aug 2023, Florents Tselai via curl-library wrote:
>
>> For reference you could check the last commit here
>> https://github.com/Florents-Tselai/curl/commit/d6ce0b1a0c619f8df1fb61a2638848d25e2aab75
>
> You have not added code
On Mon, 28 Aug 2023, Florents Tselai wrote:
Then again, it would also be an option to keep only two files tool_warc.c
and tool_warc.h in the tool directory. Which means not tweaking the curl.h
header at all and hence not making it available through curl.h Which is
probably more orthogonal; I d
On Mon, 28 Aug 2023 at 13:34, Daniel Stenberg via curl-library
wrote:
>
> I'm interested to hear others' opinions on prefered API for this functionality
> as well. I don't think we need to judge a winner approach just yet.
>
IMO, I think Brad's suggestion of a dispatch mechanism is far nicer
compa
On Mon, 28 Aug 2023, Paul Fotheringham wrote:
That thread seemed to peter out without a reply to Brad's question. I too
would benefit from an example of why calling libcurl functions from within
the callback is tricky to handle. I'm not saying it's not tricky to handle,
I just ask from a posit
On Mon, Aug 28, 2023 at 14:32 Daniel Stenberg via curl-library <
curl-library@lists.haxx.se> wrote:
> On Mon, 28 Aug 2023, Paul Fotheringham wrote:
>
> > That thread seemed to peter out without a reply to Brad's question. I
> too
> > would benefit from an example of why calling libcurl functions f
On Mon, Aug 28, 2023 at 14:59 bch wrote:
>
>
> On Mon, Aug 28, 2023 at 14:32 Daniel Stenberg via curl-library <
> curl-library@lists.haxx.se> wrote:
>
>> On Mon, 28 Aug 2023, Paul Fotheringham wrote:
>>
>> > That thread seemed to peter out without a reply to Brad's question. I
>> too
>> > would b
On Mon, 28 Aug 2023 at 22:32, Daniel Stenberg wrote:
> First out, we already deny most libcurl functions from getting called from
> their callbacks precisely because of the challenges.
>
> When libcurl calls a callback it is "in the middle of something", while when
> it returns back to the caller,
wouldn't an API that updates the list via callbacks when handles are added
and removed equal to the application just keeping the list internally like
one would have to do today? I don't really see the difference between those
two cases.
At least they way I see this is that the application does not
On Mon, 28 Aug 2023, Paul Fotheringham wrote:
To my mind you only need to consider two things to make it safe:
1. Make a copy of the handle list initially to ensure handles added by
the callbacks don't get a callback invoked on them.
2. After each callback finishes check that the next handle is
20 matches
Mail list logo