start client actor in a separate thread

[mm-near]

It seems that starting the actor in the 'current' thread (as we do right now) - is causing a bunch of issues (impacting the messages that are going to other actors)

[matklad]

Yeah, this makes total sense! One thing to note that, as we now spawn ClientActor to a different thread, we exacerbate shutdown problems. Ideally, we'd return an Arbiter, rather than ArbiterHandle from this function, and .join() it in main to make sure that all cleanup work finished.

And yeah, I feel that the fundamental problem is that whatever actix is doing internally is poorly documented, opaque, and doesn't actually help us much. Given the size and complexity of near, it makes sense for us to own our event loop, rather than to hide it in third-party actor framework without significant usage.

[bowenwang1996]

Epic! I saw this failure in CI pthread destroy mutex: Device or resource busy which is interesting.

[nikurt]

pthread destroy mutex: Device or resource busy

I hope that #6326 will fix this.