Remove the Mutex from mempool::Crawler

[teor2345]

Motivation

Here's one way to remove the Mutex from mempool::Crawler, and still spawn it in a separate task.

Solution

• always take exclusive &mut self references in mempool::Crawler methods

Review

@jvff can use whatever bits of this PR he likes.

[teor2345]

We can't take &mut self here without cloning the crawler.
And generic type inference fails if it's a static method.

We'll probably just end up sending these responses to a channel anyway.

[jvff]

Hmm, I think I'm not a fan of having this method become a function. To me it seems easier to have it as a method because it will need to use the channel that's likely to be stored inside the Crawler type.

Wouldn't it be simpler to just wait until we have updated the Tokio version, and see if that fixes the issue in a more straightforward manner?

I'm okay if you decide this is a better way to structure things, I'm just trying to figure out what's the best way forward 🤔

[teor2345]

Hmm, I think I'm not a fan of having this method become a function. To me it seems easier to have it as a method because it will need to use the channel that's likely to be stored inside the Crawler type.

Ok, I've changed it to a static method in commit 509f1fc.
And added a stub channel, to make sure that will all work.

What do you think?

Wouldn't it be simpler to just wait until we have updated the Tokio version, and see if that fixes the issue in a more straightforward manner?

I realise this question is a bit out of date - we're going to do the tokio upgrade after the mempool deadline.

I think having an instance method will work, but the ownership is a bit tricky to get right.
For an example, see PR #2661

We'll need to make sure all the fields are Clone and Sync.
But by the time we get around to that refactor, we'll have all the fields in place, so we'll know if that's reasonable.

Do you want to open a ticket for the post-tokio-upgrade refactor?

[teor2345]

The original PR got merged.