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
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
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
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
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
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
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
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
> 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
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
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
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 - -
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
> 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 =
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:
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
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
> 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
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
> 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
20 matches
Mail list logo
