Richard W.M. Jones
2023-Feb-22 16:00 UTC
[Libguestfs] [PATCH nbdkit] curl: Try to share as much as possible between handles in the pool
On Wed, Feb 22, 2023 at 04:52:35PM +0100, Laszlo Ersek wrote: ...> Seems sane to me in general, except for the fact that the documentation > at <https://curl.se/libcurl/c/CURLSHOPT_SHARE.html> writes: > > """ > CURL_LOCK_DATA_CONNECT > > Put the connection cache in the share object and make all easy handles > using this share object share the connection cache. > > Note that due to a known bug, it is not safe to share connections this > way between multiple concurrent threads. [...] > """ > > Ugh, what? If it's not safe to share the connection cache between > threads, then CURL_LOCK_DATA_CONNECT is effectively unusable, and no > connection pooling can be done. How does that *not* make this whole curl > facility useless? > > The facility in general looks super weird; what sense does it make *not* > to share some particular CURL_LOCK_DATA_xxx?I can only conclude this cannot be true. Daniel Stenberg wrote this code which definitely uses threads: https://gist.github.com/bagder/7eccf74f8b6d70b5abefeb7f288dba9b Also I did a lot of testing and didn't hit any obvious threading bugs. Nevertheless I'm not planning to integrate this patch any time soon.> LaszloThanks, Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com nbdkit - Flexible, fast NBD server with plugins https://gitlab.com/nbdkit/nbdkit
Laszlo Ersek
2023-Feb-22 16:25 UTC
[Libguestfs] [PATCH nbdkit] curl: Try to share as much as possible between handles in the pool
On 2/22/23 17:00, Richard W.M. Jones wrote:> On Wed, Feb 22, 2023 at 04:52:35PM +0100, Laszlo Ersek wrote: > ... >> Seems sane to me in general, except for the fact that the documentation >> at <https://curl.se/libcurl/c/CURLSHOPT_SHARE.html> writes: >> >> """ >> CURL_LOCK_DATA_CONNECT >> >> Put the connection cache in the share object and make all easy handles >> using this share object share the connection cache. >> >> Note that due to a known bug, it is not safe to share connections this >> way between multiple concurrent threads. [...] >> """ >> >> Ugh, what? If it's not safe to share the connection cache between >> threads, then CURL_LOCK_DATA_CONNECT is effectively unusable, and no >> connection pooling can be done. How does that *not* make this whole curl >> facility useless? >> >> The facility in general looks super weird; what sense does it make *not* >> to share some particular CURL_LOCK_DATA_xxx? > > I can only conclude this cannot be true. Daniel Stenberg wrote this > code which definitely uses threads: > > https://gist.github.com/bagder/7eccf74f8b6d70b5abefeb7f288dba9b > > Also I did a lot of testing and didn't hit any obvious threading bugs.OK, so the documentation is busted. News at 11. Can you report a bug for cURL, or should I report it sometime later?> Nevertheless I'm not planning to integrate this patch any time soon.I don't oppose merging the patch once we get a clear verdict that the documentation is wrong. Thanks! Laszlo