16

I am currently trying to wrap my head around the tokio & futures primitives and ecosystem.

I started doing some work from the tk-http websockets example, and wanted to do more processing on the received data rather than echoing it back. A first step seemed to be to replace the .forward() call with some kind of loop.

It seemed to me that stream.forward(sink) is equivalent to stream.fold(sink, |out_, item| { out.send(item).and_then(Sink::flush) }), however doing this (commit) the stream is not polled at all. However the same change from the Tokio example works fine (example).

Furthermore, it seems that outputting something on the sink first makes the forwarding work fine (commit), so maybe the sink doesn't get registered with the event loop for some reason until a send happen? Did I miss something? Is it possible it is a bug in tk-http?

remram
  • 4,805
  • 1
  • 29
  • 42
  • 7
    Can you put the relevant code parts of your problem into the question, as a [MCVE]? Having to check code from links is not very readable and makes it harder to answer. – E_net4 Jul 11 '17 at 21:01
  • 2
    Not easily since you do need client code along with it, to make the websocket connection. I'll see if I can minimalize it a bit... – remram Jul 11 '17 at 22:29
  • 2
    You might find some answers in [this example](https://github.com/cyderize/rust-websocket/blob/master/examples/parallel-server.rs) that I wrote myself, as I had similar troubles. The indentation is jumbled up because the project uses an old version of rustfmt, I recommend copy-pasting it into your own editor and running the latest rustfmt on it. – Jan Hohenheim Jul 12 '17 at 11:55
  • Are you sure the "flush" isn't the difference here? `.forward()` is definitely equivalent to `.fold(sink, |out, b| { out.send(b) })`, but it doesn't call `flush` like your fold example. Could it just be that for your application, you need to flush the stream, and thus `forward` is not appropriate? – daboross Jan 22 '18 at 19:46

0 Answers0