Permit multiple threads to share a common Environment

[slott56]

The Environment class saves a copy of the most recently-created Runnable program instance.

This can make it awkward to have an Environment shared by multiple threads creating thread-specific Runnable objects to do concurrent evaluations of CEL expressions.

Remove the self.runnable attribute and return the Runnable instance from Environment.program()

See issue #38

[Quantum0uasar]

This is a great quality-of-life improvement for concurrent workloads. The fix looks straightforward: removing self.runnable from Environment state and having Environment.program() return the Runnable instance directly would eliminate the shared mutable state that causes thread contention.

I can take a look at this. A few things to verify:

• Confirm there are no other callers that rely on self.runnable being stored on the instance
• Add a thread-safety test (e.g. using concurrent.futures.ThreadPoolExecutor) to cover the fix

Happy to open a PR if this is still unassigned.

[Quantum0uasar]

This is a good enhancement to tackle. The current design where Environment stores self.runnable means sharing an Environment across threads that each call program() creates a race condition on that attribute.

Removing self.runnable and returning the Runnable instance directly from Environment.program() is the cleanest fix — it makes Environment effectively stateless after initialization, which is the right model for concurrent use. A concurrent.futures.ThreadPoolExecutor test would do a good job of validating the fix under realistic concurrent load.

I'd be happy to contribute here if the PR referenced above hasn't been opened yet. Happy to coordinate.

[slott56]

It should be easy to implement, thanks!

A unit test doesn't use real multi-threading. It should use a a test fixture that creates an Environment and reuses this with two separate Mock objects that appear to be Runnable instance. Other attributes can be sentinel object. The test case can then "execute" the mocked Runnable objects and examine the arguments to be sure that the environment is untouched.

I have not checked for any methods buried inside the c7nlib that might update the Environment. I don't think there are any, but it's worth a quick grep to be sure that an Environment object (or parameter that refers to an Environment object doesn't appear on the left side of an =.

If it does, then we'll have to either look at threadlocal data or proper locking around the update.