Issue running multiple instances of bind_listen_serve in same process

[casey]

Thanks for this crate!

We're writing a web service that uses rustls-acme to get TLS certificates from Let's Encrypt. We have integration tests that run in the same process, and are running into issues when running two instances of rustls-acme::bind_listen_serve simultaneously.

We ran into this originally when running one instance of rustls-acme::bind_listen_serve with no cache directory configured, and then running an instance with a cache directory configured. When doing this, it seemed like the second instance didn't run with a cache directory.

I wanted to open this issue to ask, is there any shared state which might cause problems when running multiple instances of rustls-acme::bind_listen_serve in the same process? I poked around looking for things like lazy_static, or const mutexes, but couldn't find anything.

[FlorianUekermann]

Cool. Glad you like it.

There's no shared state. You didn't miss anything there. Is your code/test publicly accessible?

[casey]

There's no shared state.

Thanks for confirming!

You didn't miss anything there. Is your code/test publicly accessible?

We actually figured it out, we were mixing tokio and async_std, which somehow worked when we did it once, but didn't when we did it twice in the same process. We switched to using the runtime-independent API, which fixed the problem. So PEBCAK 😅

[FlorianUekermann]

We actually figured it out, we were mixing tokio and async_std, which somehow worked when we did it once, but didn't when we did it twice in the same process. We switched to using the runtime-independent API, which fixed the problem. So PEBCAK

Nice. The next major version will make this easier by making both the higher and slightly lower level APIs runtime independent. I won't get around to it until December, but I'll have a lot more time for improving this crate after that.