Hyper: Sync for Handlers is problematic for types like Sender

[reem]

Sender is not Sync, and is instead meant to be Cloned for every concurrent user. Right now, hyper doesn't expose a way to make this happen, and instead forces you to use a Mutex<Sender<T>>, which is subpar.

My first attempt to fix this was to write a copy-on-access wrapper that lifts types from Clone to Sync, but this is actually unsafe since for non-Sync types like RefCell or Rc calling clone concurrently causes bad behavior.

The immediate resolution I see here to is to just bound by Send + Clone instead of Send + Sync, after which you could recover the current behavior by using Arc inside of your type. Alternatively, we could add a separate method for Send + Clone handlers and Send + Sync handlers, wrapping them in an Arc or not depending on which method is used.

[seanmonstar]

I have heard the same a couple times now in rust-webdev. I've been thinking
of changing to a Clone bounds instead of Sync...

On Tue, Jan 13, 2015, 2:33 PM Jonathan Reem [email protected]
wrote:

Sender is not Sync, and is instead meant to be Cloned for every
concurrent user. Right now, hyper doesn't expose a way to make this happen,
and instead forces you to use a Mutex> which is subpar.

My first attempt to fix this was to write a copy-on-access wrapper that
lifts types from Clone to Sync, but this is actually unsafe since for non-
Sync types like RefCell or Rc calling clone concurrently causes bad
behavior.

The immediate resolution I see here to is to just bound by Send + Clone
instead of Send + Sync, after which you could recover the current
behavior by using Arc inside of your type. Alternatively, we could add a
separate method for Send + Clone handlers and Send + Sync handlers,
wrapping them in an Arc or not depending on which method is used.

—
Reply to this email directly or view it on GitHub
https://github.com/hyperium/hyper/issues/248.

[seanmonstar]

We talked through this on IRC. Simple synopsis is that if it were Clone, users could easily have state on their handler that they think is modified with each request, but instead, it would have been cloned several times and not modify what they hoped. Instead, it's better force the user to make sure their state is synchronized.

[iwinux]

So sending data to channel in hyper handler will block for acquiring lock even we use an async sender?