Add a bad workaround for a deadlock: we should look for a better one.

This commit is contained in:
Nick Mathewson 2020-09-25 16:10:53 -04:00
parent 6071b0e903
commit c0ee910413
2 changed files with 14 additions and 4 deletions

View File

@ -288,7 +288,10 @@ impl ClientCirc {
// assuming it's the last hop.
// XXXX Both a bound and a lack of bound are scary here :/
let (sender, receiver) = mpsc::channel(128);
// XXXX This bound is far too high, but without it we can deadlock.
// XXXX See note in ReactorCore::handle_relay_cell.
let (sender, receiver) = mpsc::channel(1024);
let mut c = self.c.lock().await;
let hopnum = c.hops.len() - 1;
@ -639,6 +642,8 @@ impl StreamTarget {
self.window.take(&()).await;
}
let cell = RelayCell::new(self.stream_id, msg);
// XXXX This can deadlock if the reactor is blocked;.
// XXXX See note in ReactorCore::handle_relay_cell.
let mut c = self.circ.c.lock().await;
c.send_relay_cell(self.hop, false, cell).await
}

View File

@ -192,7 +192,7 @@ impl ReactorCore {
// Decrypt the cell. If it's recognized, then find the
// corresponding hop.
let (hopnum, _tag) = circ.crypto.decrypt(&mut body)?;
let (hopnum, _) = circ.crypto.decrypt(&mut body)?;
let hop = circ.get_hop_mut(hopnum).unwrap(); // XXXX risky
// Decode the cell.
@ -231,10 +231,15 @@ impl ReactorCore {
// XXXX handle errors better. Does this one mean that the
// the stream is closed?
// XXXX should we really be holding the mutex for this?
// XXXX reject cells that should never go to a client,
// XXXX like BEGIN.
// XXXXX If possible we should try to stop holding the mutex
// XXXXX for this:
// XXXXX This send() operation can deadlock if the queue
// XXXXX is full and the other side is trying to send a sendme.
// XXXXX That's why I've chosen a really high queue length.
// XXXXX I should fix that.
let result = s
.send(msg)
.await