a94d6fe706
Referring to Daniel's article [1], making the init function thread-safe was the last bit to make libcurl thread-safe as a whole. So the name of the feature may as well be the more concise 'threadsafe', also telling the story that libcurl is now fully thread-safe, not just its init function. Chances are high that libcurl wants to remain so in the future, so there is little likelihood of ever needing any other distinct `threadsafe-<name>` feature flags. For consistency we also shorten `CURL_VERSION_THREADSAFE_INIT` to `CURL_VERSION_THREADSAFE`, update its description and reference libcurl's thread safety documentation. [1]: https://daniel.haxx.se/blog/2022/06/08/making-libcurl-init-more-thread-safe/ Reviewed-by: Daniel Stenberg Reviewed-by: Jay Satiro Closes #8989 |
||
|---|---|---|
| .. | ||
| Android | ||
| DOS | ||
| OS400 | ||
| vms | ||
| Makefile.am | ||
| README | ||
README
_ _ ____ _
___| | | | _ \| |
/ __| | | | |_) | |
| (__| |_| | _ <| |___
\___|\___/|_| \_\_____|
PACKAGES
This directory and all its subdirectories are for special package
information, template, scripts and docs. The files herein should be of use for
those of you who want to package curl in a binary or source format using one
of those custom formats.
The hierarchy for these directories is something like this:
packages/[OS]/[FORMAT]/
Currently, we have Win32 and Linux for [OS]. There might be different formats
for the same OS so for Linux we have RPM as format.
We might need to add some differentiation for CPU as well, as there is
Linux-RPMs for several CPUs. However, it might not be necessary since the
packaging should be pretty much the same no matter what CPU that is used.
For each unique OS-FORMAT pair, there's a directory to "fill"! I'd like to
see a single README with as much details as possible, and then I'd like some
template files for the package process.