nice this looks good!

This feature was added to anyio specifically for httpcore, so I'm going to merge it even though I'm the only review

@graingert No. Please don't do that on this PR.

This was my latest comment regarding this... #922 (comment)

Here's a comment that'd make me wary of jumping onto fast_acquire=True... agronholm/anyio#761 (review)

Happy for a revert, does #927 remove a lock on the async code path and therefore make this PR redundant?

I'm not talking about #927 or directing my attention there at the moment.

Revert PR at #1002.

When will the tag related to this change here and on httpx will be relaesed?

I'm confused about what happened here; what was the technical issue?

@ofek #953 (comment) / agronholm/anyio#761 (review)

Ah I missed the second comment, thanks! I don't do enough async in Python to know what that means but I'll take a deeper dive eventually because such performance improvements always intrigue me.

@graingert No. Please don't do that on this PR.

This was my latest comment regarding this... #922 (comment)

Here's a comment that'd make me wary of jumping onto fast_acquire=True... agronholm/anyio#761 (review)

Can you explain this to me, as it didn't make a lick of sense to me? Was this about fast_acquire=True skipping the checkpoint? asyncio.Lock never had that checkpoint to begin with, so what do you suppose is gained by reverting the commit?

what do you suppose is gained by reverting the commit?

@agronholm So. The priority at the time was bumping a release from 1.0.7 to 1.0.8 in order to resolve #1005.

Mixing in other concerns introduces risk, rather than just prioritising the necessary fix for Python 3.14.0a6.

Also I've been doing some background work on a significantly simplified implementation. I've got a connection pool approach that's smaller, more readable, and easier to reason about. It also happens to result in faster & more stable response characteristics under load. (significant improvement vs. current httpx, marginal improvement vs. aiohttpx)

I'm not ready to share the work publicly yet, tho will update shortly.

what do you suppose is gained by reverting the commit?

@agronholm So. The priority at the time was bumping a release from 1.0.7 to 1.0.8 in order to resolve #1005.

Mixing in other concerns introduces risk, rather than just prioritising the necessary fix for Python 3.14.0a6.

Also I've been doing some background work on a significantly simplified implementation. I've got a connection pool approach that's smaller, more readable, and easier to reason about. It also happens to result in faster & more stable response characteristics under load. (significant improvement vs. current httpx, marginal improvement vs. aiohttpx)

I'm not ready to share the work publicly yet, tho will update shortly.

OK, thanks for the quick response. I was previously left with the impression that you had reservations about fast_acquire, but perhaps I misunderstood.

I was previously left with the impression that you had reservations about fast_acquire, but perhaps I misunderstood.

I don't really know enough about fast_acquire to take an informed stance on that.

(Incidentally, thanks so much for your work on anyio, and helping bring structured concurrency patterns to Python's asyncio.)

Yeah, so the summary is that with fast_acquire=True, AnyIO locks work pretty much the same way as asyncio locks (hence the performance parity). It does that by skiping a checkpoint, which on Trio is considered faux pas where everything with async with, async for or await should go through a checkpoint, but on asyncio there are no such considerations. Basically asyncio cuts corners and is faster because of that. fast_acquire=True just cuts corners the same way asyncio.Lock does.