Refactoring light-base/src/json_rpc_service.rs

[tomaka]

The code in json_rpc_service.rs is way too cumbersome and complicated, and more functionalities should be added to the request_subscriptions state machine in order to make it more simple.

Unfortunately, the logic of this code is inherently complicated. When a chainHead_unstable_body for example is called, we need to look up in the corresponding follow subscription to check whether the block is still pinned.

I can see two ways of making it work:

• request_subscriptions could store, for each subscription, a task and a user data. When the user wants to unsubscribe, we ask the request_subscriptions to abort the task (after examining the user data, to be sure that the type of the subscription matches). The user data is behind a Mutex and would store, in the case of a follow subscription, the FollowSubscription struct that currently exists. This solution is pretty similar to what already is done in the code.

• request_subscriptions could store, for each subscription, a task and a channel that can send messages to that task. The channel would be provided by the request_subscriptions rather than done manually in order to add some safety around locking Mutexes. When the user wants to unsubscribe, we send a message to the subscription in question which then politely shuts down. When the user calls for example chainHead_unstable_body, we send a message to the subscription in question as well, which then starts the body request subscriptions. The existing FollowSubscription would be a local variable in the task of the follow subscription.

The latter is more safe in terms of Mutex locking, as it would prevent all accidental deadlocks, but maybe also a bit more complicated.

[tomaka]

cc #284 which was the first step

[tomaka]

I'm leaning towards the second solution, as the lack of mutexes seems more clean to me.

[tomaka]

The last step would be to refactor chain_head.rs to use a struct rather than one big async closure.

[tomaka]

Done after #793