1

I am creating a webserver using tokio. Whenever a client connection comes in, a green thread is created via tokio::spawn.

The main function of my web server is proxy. Target server information for proxy is stored as a global variable, and for proxy, all tasks must access the data. Since there are multiple target servers, they must be selected by round robin. So the global variable (struct) must have information of the recently selected server(by index).

Concurrency problems occur because shared information can be read/written by multiple tasks at the same time. According to the docs, there seems to be a way to use Mutex and Arc or a way to use channel to solve this.

I'm curious which one you usually prefer, or if there is another way to solve the problem.

kmdreko
  • 42,554
  • 6
  • 57
  • 106
yjlee
  • 363
  • 1
  • 14
  • Does this answer your question? [How do I create a global, mutable singleton?](https://stackoverflow.com/questions/27791532/how-do-i-create-a-global-mutable-singleton) – Jmb Jul 26 '22 at 06:25

1 Answers1

1

If it's shared data, you generally do want Arc, or you can leak a box to get a 'static reference (assuming that the data is going to exist until the program exits), or you can use a global variable (though global variables tends to impede testability and should generally be considered an anti-pattern).

As far as what goes in the Arc/Box/global, that depends on what your data's access pattern will be. If you will often read but rarely write, then Tokio's RwLock is probably what you want; if you're going to be updating the data every time you read it, then use Tokio's Mutex instead.

Channels make the most sense when you have separate parts of the program with separate responsibilities. It doesn't work as well to update multiple workers with the same changes to data, because then you get into message ordering problems that can result in each worker's state disagreeing about something. (You get many of the problems of a distributed system without any of the benefits.)

Channels can work if there is a single entity responsible for maintaining the data, but at that point there isn't much benefit over using some kind of mutual exclusion mechanism; it winds up being the same thing with extra steps.

cdhowie
  • 158,093
  • 24
  • 286
  • 300
  • It was well understood. I think I should use a combination of Arc and Mutex. One question, is there any difference between using the mutex of ```parking_lot``` crate and the mutex of ```tokio```? – yjlee Jul 26 '22 at 07:06
  • 1
    @yjlee Yes. The mutexes from `std` and `parking_lot` aren't async, which means acquiring the lock from an async function running on tokio will block the entire worker thread, as tokio can't run other tasks on it. You should never call blocking non-async functions from async functions. Prefer using facilities from your async runtime when possible. If you can't find an async version of something, you can make it async-safe by using [`spawn_blocking`](https://docs.rs/tokio/latest/tokio/task/fn.spawn_blocking.html). – cdhowie Jul 26 '22 at 07:59