Ordering between crossbeam channels

Wow, what? I managed to help somebody out, without having the faintest idea what they actually want to do? All the while thinking I was being dumb and missing a point somewhere.

Excellent. Negative code days are some of the sweetest.

Bad news. After a few hours at the keyboard, it looks like I'll have to stick with the two channel solution. It turns out that I'm reading one channel from one place in the code, and the other channel elsewhere. I thought I could restructure the code to merge them, but I can't with any reasonable amount of effort. Maybe if I hadn't painted myself into this particular corner ...

Please don't be shy about asking questions. When I was a professor (of astronomy of all things), I told my students that the only dumb question is the one you don't ask.

Oh, sorry if I have wasted your time with a naive suggestion.

Not knowing exactly what you are doing, that sounds a bit off to me. If your thread is doing something like this:

    ...
    // One place in the code
    let x =  recv.recv().unwrap())
    // Do something with x
    ...
    // The other place in the code
    let y =  recv.recv().unwrap())
    // Do something with y

That implies to me that 'x' and 'y' are expected to be of different types with correspondingly different "Do something" parts (otherwise you would just read them all in one place).

Hence, I presume, the original desire for two channels, delivering different types, in the right order. Am I right?

Typically I would model this as a state machine. Messages would only be received from one channel in one place and the required action would be dispatched from there, depending on the type of message and the current state.

Typically because my mind is too small to manage anything else :frowning:

I guess perhaps you have enough code now that rearranging it into a state machine is too much of a chore.

Ha. I think I have asking dumb questions as a skill listed in my CV. It's a useful skill when testing safety critical systems... "What happens when I do this (dumb thing) ....?"

It is a state machine, but the details depend on the type of device we're modeling. Some require a second message others don't. We've define a trait Device with a method handshake. The code is basically,

loop {
    msg = rx1.recv()?;
    do_something(msg);
    device.handshake();
}

I tried moving rx2.recv() into the loop, but the resulting code reminded me too much of the spaghetti code I used to write in Basic.

I might have come up with a different design had I realized I could reuse rx1.recv(), but I think it's too late now.

1 Like

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.