using the new async APIs requires a paradigm shift. instead of sending
EventLoopPromises across concurrency domains via
AsyncStreams, it’s a lot more natural to just use native swift actor isolation.
given a use case such as: triggering a network fetch when receiving a server request, i am discovering the new APIs are colliding headfirst with the reality that
ClientBootstrap is not
which means… you cannot store anything that wraps a
ClientBootstrap anywhere in an actor. why? because actors are re-entrant, and if you call any
async functions that touch that
ClientBootstrap, you are effectively sharing it across concurrency domains, and you will rightly get clobbered with concurrency warnings.
anyway, these aren’t new complaints, and people using
ClientBootstraps with swift concurrency for different reasons than me have already been running into this problem for a while. for now i’ve just resorted to building a new
ClientBootstrap on every request, since that avoids any sharing problems. but i really hope adoption of the new async APIs will put the final nail in the coffin for
ClientBootstrap. this type has no place in the async/await world and i personally think replacing it should be the next priority for NIO.