Hello,
This morning we got a fresh issue [1] filed that involves the NSS library.
When I started to investigate this I ran a few google searches for some of the
invovled functions in NSS, such as PR_Recv, only to realize that there just is
no documentation for this to be found online anymore -
On 1/27/2022 5:59 PM, Ray Satiro wrote:
> You can bisect the issue.
It just occurred to me you will actually have to do a reverse bisect,
since you would be looking for when an issue was fixed not when it was
broken. git bisect now has terms old and new for that. So for example
curl-7_64_1 would
On 1/27/2022 12:45 PM, Frank Spano via curl-library wrote:
> Our program is sending ~800 requests per minute, and experiencing
> crashes every ~5 minutes. We verified that every CurlEasy handle is
> allocated/deallocated properly (no nullptr after allocation, no double
> frees happening). When enco
On Thu, 27 Jan 2022, Frank Spano via curl-library wrote:
Since installing and building with curl 7.80.1, we’re experiencing no issues
- the program is no longer crashing. Our issue was resolved, but we would
like to know why this was happening - is this a known bug?
There are 2297 documented
On Thu, Jan 27, 2022 at 08:20:31AM +0100, Daniel Stenberg wrote:
> I don't think it's related to TLS. If it was, you should be able to repro
> using HTTPS using HTTP/1.1 as well. I rather suspect it is about HTTP/2 and
> that each transfer is a stream inside a connection, so a failed transfer
> onl
Hello,
We’re experiencing an issue with a QT (single threaded) application when
using curl 7.64.1 (x86_64-apple-darwin20.0) - packaged on MacOS.
——-
curl 7.64.1 (x86_64-apple-darwin20.0) libcurl/7.64.1 (SecureTransport)
LibreSSL/2.8.3 zlib/1.2.11 nghttp2/1.41.0
Release-Date: 2019-03-27
Protoc
On Thu, Jan 27, 2022 at 12:57 PM Daniel Stenberg wrote:
> On Thu, 27 Jan 2022, James Read via curl-library wrote:
>
> > it seems to me that cURL project needs to work on optimizing bandwidth
> usage
> > above all else.
>
> Everyone of course wants their favorite use case getting extra attention.
On 27-Jan-22 06:25, Gavin Henry wrote:
Perhaps the win was from reducing strlen() calls? They are often overused, and
while they can be optimized to some extent, they are inherently slow at
runtime. Unless a compiler is smart enough to detect a string constant, where
x is a constant replacin
On 27-Jan-22 07:47, James Read via curl-library wrote:
On Thu, Jan 27, 2022 at 12:06 PM Henrik Holst
wrote:
I wonder if the results that you see from that example is due to
the short life of each connection, aka most of the time there is
spent on the tcp-handshake (and possible
On Thu, 27 Jan 2022, James Read via curl-library wrote:
it seems to me that cURL project needs to work on optimizing bandwidth usage
above all else.
Everyone of course wants their favorite use case getting extra attention.
Bandwidth optimizing, minimizing foot-print, reducing mallocs or why n
Well that single use drops off the cliff is "by design" due to the tcp
scaling window, it usually starts of really small and grows over time but
before it have managed to grow the fetch is complete and with close() and
use of a new connection it have to start over again.
/HH
Den tors 27 jan. 2022
On Thu, Jan 27, 2022 at 12:06 PM Henrik Holst
wrote:
> I wonder if the results that you see from that example is due to the short
> life of each connection, aka most of the time there is spent on the
> tcp-handshake (and possible the tls handshake on top of it all) combined
> with a small initial
I wonder if the results that you see from that example is due to the short
life of each connection, aka most of the time there is spent on the
tcp-handshake (and possible the tls handshake on top of it all) combined
with a small initial tcp window that never gets large enough before the
page has be
On Thu, Jan 27, 2022 at 11:48 AM Henrik Holst via curl-library <
curl-library@lists.haxx.se> wrote:
> depends on architecture, AFAIK if you compile for 64-bit Windows then
> __fastcall is completely ignored since the MS compiler uses the "Microsoft
> x64 calling convention" there regardless of wha
depends on architecture, AFAIK if you compile for 64-bit Windows then
__fastcall is completely ignored since the MS compiler uses the "Microsoft
x64 calling convention" there regardless of what one types according to
https://en.wikipedia.org/wiki/X86_calling_conventions
/HH
Den tors 27 jan. 2022
Henrik Holst wrote:
strlen() is one clear candidate for some optimizations, often however it is declared as __attribute_pure__ so the
Another candidate for MSVC would be 'cl -Gr'.
(build for fastcalls internally). But that's not
possible now due to things like:
cookie.c(1433): error C2440: '
On 27-Jan-22 05:59, Henrik Holst wrote:
sizeof have been a compile time constant since inception, however
since C99 it can also be used on variable length arrays and for those
it of course have to be a runtime operation. Perhaps OpenLDAP used
variable length arrays to a huge degree?
strlen()
> Perhaps the win was from reducing strlen() calls? They are often overused,
> and while they can be optimized to some extent, they are inherently slow at
> runtime. Unless a compiler is smart enough to detect a string constant,
> where x is a constant replacing strlen(x) with (sizeof(x)-1) ca
sizeof have been a compile time constant since inception, however since C99
it can also be used on variable length arrays and for those it of course
have to be a runtime operation. Perhaps OpenLDAP used variable length
arrays to a huge degree?
strlen() is one clear candidate for some optimizations
On 27-Jan-22 04:27, Daniel Stenberg via curl-library wrote:
On Thu, 27 Jan 2022, Gavin Henry wrote:
I remember in the OpenLDAP project when they removed/reduced the
amount of times sizeofs that were used for performance gains.
When is sizeof ever a slow operation?
As we're only using C89, ou
I'll dig out the email thread and link to it when I find it :)
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
On Thu, 27 Jan 2022, Gavin Henry wrote:
I remember in the OpenLDAP project when they removed/reduced the amount of
times sizeofs that were used for performance gains.
When is sizeof ever a slow operation?
As we're only using C89, our sizeof uses are only ever for types/structs, and
I can't s
I remember in the OpenLDAP project when they removed/reduced the
amount of times sizeofs that were used for performance gains.
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Hello,
Every now and then libcurl-using application authors ask for an API to help
them extract contents of specific HTTP response headers. There are many
libcurl-using applications and there are many of those that need to extract
header contents, so providing a generic and single way to do th
24 matches
Mail list logo
