Per-session kore-rpc server state

[goodlyrottenapple]

In order to use the kore-rpc server concurrently in a safe way, we modify the server to create a new server state per each session. This way, each client will get the same initial server state and calls to add-module will always be safe, because the added modules are per session and not shared between different clients. This of course means that each client has to send the required modules to the server separately.

Part of runtimeverification/hs-backend-booster#383

[jberthold]

LGTM .. .although unclear how kore-rpc-client should change to use that

[tothtamas28]

The ability to share modules between clients in a controlled way can be very useful, I'd prefer a solution that enables that. Did you consider the proposal under runtimeverification/hs-backend-booster#383 (comment)?

[goodlyrottenapple]

The ability to share modules between clients in a controlled way can be very useful, I'd prefer a solution that enables that.

Is this due to performance? Do you expect these modules to be very big?

Did you consider the proposal under runtimeverification/hs-backend-booster#383 (comment)?

I was working under the assumption that we simply want to avoid module clashes and tweaking the global state to only be a session state seemed like a much simpler solution. Using IDs and especially importing modules via IDs whilst maintaining module names completely disjoint from said IDs seemed a much more substantial change to both back-ends.

[tothtamas28]

Is this due to performance? Do you expect these modules to be very big?

No, it's for ease of programming against the API.

Using IDs and especially importing modules via IDs whilst maintaining module names completely disjoint from said IDs seemed a much more substantial change to both back-ends.

Implementation effort should of course be taken into consideration. Can you post your feedback on the design issue so that we can iterate on it?