Why use a Mutex for the token?

[Bogpan]

Hi, I'm working on a similar project and was wondering why rspotify uses an Arc<Mutex<Option<Token>>>, instead of just an Option<Token>.

Note that the token is wrapped by a Mutex in order to allow interior mutability. This is required so that the entire client doesn’t have to be mutable (the token is accessed to from every endpoint).

I've read the note from the get_token method, but I don't quite understand why the entire client could just be mutable. Isn't a Mutex unnecessary unless the token is being accessed from separate threads?

[ramsayleung]

Let take a glance at the function signature of get_token:

    /// Note that the token is wrapped by a `Mutex` in order to allow interior
    /// mutability. This is required so that the entire client doesn't have to
    /// be mutable (the token is accessed to from every endpoint).
    fn get_token(&self) -> Arc<Mutex<Option<Token>>>;

If we choose to use Option<Token> instead of Arc<Mutex<Option<Token>>>, we are unable to update the token field, because it's immutable.

Then, there are two options come to our mind,

the first and most straight forward one, change the function signature get_token to mark it as mutable fn get_token (&mut self), it's easy.

But the problem is that we need to surface this mutability to the library users, all existing code and packages which depend on rspotify need to update their declaration from:

let rspotify = xxxx..

// to

let mut rspotify = xxx.

It means we break the all backward compatibility, even though rspotify hasn't released the 1.0 version, but we want to minimize the breaking changes.

The second option is to impose interior mutability, with Arc<Mutex>

[Bogpan]

Oh yes, that is of course the right path for backwards compatibility, but I saw it used to be Option<Token> in the past, I was wondering why that changed?

[ramsayleung]

Yes, because in the past, we only read the token value from get_token function, we won't modify the token value.

But when we wanted to implement the automatic re-authentication feature, this problem surfaced to us: #4

[Bogpan]

Yup, I've (partly) read through that issue before, but I don't understand this:

The complicated part comes in when we have to refresh the token: this is a mutable operation, so the method would be mutable as well, and thus propagate up until the endpoints, which would have to be mutable, too.
In the end we'd have a fully mutable Spotify client, which would be much harder to use than an immutable one. But not sure if there's any way to fix this. Perhaps with cells or similars.

Why is that an issue? Why not just have a mutable client? There might be something obvious I'm not seeing.

[ramsayleung]

1. backwards compatibility as mentioned as above
2. higher maintenance cost for mutable client.

[Bogpan]

1. What backwards compatibility? As I've already mentioned, the token field used to be an Option<Token> and was changed at some point. I was asking why it was changed from an Option<Token> to an Arc<Mutex<Option<Token>>>.
2. Could you elaborate?

[ramsayleung]

As I've already mentioned, the token field used to be an Option and was changed at some point. I was asking why it was changed from an Option to an Arc<Mutex<Option>>

As I've already mentioned before, at the beginning, the get_token function is read only, we don't need to Update/Modify the token value, so it could return Option<Token>.

Then, we would like to implement re-authentication feature, which required to modify the token field, as I've mentioned above, there are two solutions for this mutable requirement.

the first and most straight forward one, keep the function get_token and add a new function set_token and mark it as mutable fn set_token (&mut self), it's easy.

But the problem is that we need to surface this mutability to the library users, all existing code and packages which depend on rspotify need to update their declaration from:

let rspotify = xxxx..

// to

let mut rspotify = xxx.

It means we break the all backward compatibility, even though rspotify hasn't released the 1.0 version, but we want to minimize the breaking changes.

The second option is to impose interior mutability, update get_token from Option<Token> to Arc<Mutex<Option<Token>>>

This is how the get_token function evolved, which part is confusing you?

[Bogpan]

Ah, I see I didn't understand the issue fully. I didn't cosider the fact that a mutable client would break backwards compatibility, my bad. Thanks for clearing it up!