Controlling message loops without spinOnce()

[icefoxen]

A problem I commonly have in rospy is the lack of a spinOnce() equivalent. I often write code that interfaces ROS systems with other things, and that code needs to drive the event loop on its own, something like this pseudocode:

loop {
    let data = wait_for_data(serial_port)?;
    let msg = translate_message(data);
    if rosrust::is_ok() {
        publisher.publish(msg);
    }
}

Or:

let shared_data = Arc::new(data);
let subscriber = rosrust::subscribe("/some_topic", 10, |msg| get_interesting_bits_of_message(msg, shared_data));
loop {
    send_new_state(shared_data, serial_port)?;
    if rosrust::is_ok() {
    }
}

But this doesn't actually seem to work the way that roscpp::spinOnce() does. In the first case, as far as I can tell it's possible for my message to never get published, or get published at weird places, and in general there doesn't seem to be a way to tell ROS to just flush its outgoing queue and get on with life. In the second case, it seems to work until I ctrl-C the program, and then the interrupt gets eaten and the program never stops running until I hard kill it -- just like rospy.

Plz halp? All I want is to be able to sensibly control my message loops and tell my program when to actually move data around. I was hoping that Rust would do a better job of this than Python, and so far that's not been the case. (Though otherwise I'm real impressed with how well things work, I have to say that rosrust_msg is pure insanity and I love it.)

[pmirabel]

Hi,
I would be glad to help, but I do not really understand what prevent you to finely control your eventloop (Rust indeed offer a lot of way to accomplish that).

[adnanademovic]

This is because everything is running in parallel, like in rospy, rather than a hybrid of channels in parallel and an event loop in the same thread as the node's logic. In all implementations, data is getting sent between topics, and overwritten/discarded if an overflow happens.

You can block and synchronize threads to your liking - it will not cause anything outside of the subscriber handler to grind to a halt. The only thing that will happen is that if the buffer of messages goes over the 10 you passed as a parameter, messages get dumped.