Is esper Thread-Safe for Multi-threaded Environments?

[GeorgesAlkhouri]

I'm considering using esper in a project that requires multi-threading. I'd like to know if the library is designed to be thread-safe. Specifically, are there any examples or documentation on how to properly use esper in a multi-threaded environment?

Thank you for your time and effort in maintaining this library!

[benmoran56]

Hello Georges,

Thanks for your interest in esper. Current no, esper does not do any type of locking. I will revisit this once future Python No-GIL builds are released.

At a minimum, locking will need to be done around Component types. It won't work if two Processors were iterating over ComponentA at the same time, for instance.

esper also has internal caching for component queries. This may need to be changed as well, but perhaps not.

[GeorgesAlkhouri]

Thank you for clarifying the details. Our game is designed to be a client/server, multi-user, turn-based game. In this setup, executing the esper process pipeline is expected to be efficient, potentially running once every two seconds. Given that performance is not a concern in our use case, we are considering wrapping esper and its required state within a new Python Process for every request. This would be executed on a per-user-request basis.

[benmoran56]

I haven't personally used esper in this way, but it should be effective. You can import esper inside of each process if you want to avoid all shared state entirely. Using a specific World context for each Process should also prevent conflicts (esper.switch_world(name)).

[GeorgesAlkhouri]

Thanks again, as of now it works like a charm, isolating esper via a new process.

[benmoran56]

Great, glad I'm glad it worked out.