I am now happy with this, we just need to rebase on #786 once it's merged.

Also, this branch is about 20-40% faster depending on what you are doing, and there is other low hanging fruit to improve perf but I don't have any more time for this right now, so once it's merged we can look at improving performance further.

Here is perf comparison:

fix-thread-unsafe

Generated log placed in /home/samuel/Documents/ioquatix/github-changelog-generator/lib/CHANGELOG.md
bundle exec ../bin/github_changelog_generator --no-http-cache -u  -p  -t   25.64s user 0.88s system 26% cpu 1:39.57 total

async-http-faraday (with faraday 1.0)

Generated log placed in /home/samuel/Documents/ioquatix/github-changelog-generator/lib/CHANGELOG.md
bundle exec ../bin/github_changelog_generator --no-http-cache -u  -p  -t   7.70s user 0.48s system 14% cpu 57.872 total

changelogs

They are the same

koyoko% shasum CHANGELOG*
390b735e55a97578f597d0919eedf3e14f43ea07  CHANGELOG-async.md
390b735e55a97578f597d0919eedf3e14f43ea07  CHANGELOG-threads.md

Just for fun, here is master:

Generated log placed in /home/samuel/Documents/ioquatix/github-changelog-generator/tmp/CHANGELOG.md
bundle exec ../bin/github_changelog_generator -u github-changelog-generator -  26.77s user 1.08s system 30% cpu 1:31.09 total
koyoko% shasum *.md
390b735e55a97578f597d0919eedf3e14f43ea07  CHANGELOG-async.md
8091e439ec6528a1c50248721a8c68c0c238e31b  CHANGELOG.md
390b735e55a97578f597d0919eedf3e14f43ea07  CHANGELOG-threads.md

@ioquatix can you rebase against the latest master?

Rebased.

Thanks again, merging.

I'd love to see this in a released version.

Thanks for your enthusiasm!

When I made this PR, I didn't know how to efficiently reuse the persistent connections because it was not possible to scope resources to the outer reactor. But now that it is possible using transient tasks, there is some more performance to be had. We don't need to close the persistent internet connection after every block of requests. This is something we should revisit.

@olleolleolle I'm not sure if you have the ability to do this, but could we get this released in a new RubyGems version? Without this fix the gem is known to produce nondeterministic results (see #774) so it's unusable for me.