Skip to content

Commit

Permalink
make send() synchronous and drop all the various queues
Browse files Browse the repository at this point in the history
  • Loading branch information
rdeits committed Feb 10, 2020
1 parent f1949ec commit 92f939f
Showing 1 changed file with 5 additions and 1 deletion.
6 changes: 5 additions & 1 deletion src/visualizer.jl
Original file line number Diff line number Diff line change
Expand Up @@ -117,7 +117,11 @@ end

function Base.write(core::CoreVisualizer, data)
for connection in core.connections
WebSockets.writeguarded(connection, data)
if isopen(connection)
WebSockets.writeguarded(connection, data)
else
delete!(core.connections, connection)
end
end
end

Expand Down

3 comments on commit 92f939f

@peteflorence
Copy link

@peteflorence peteflorence commented on 92f939f Apr 17, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@rdeits is there a way I can make meshcat-python not build a queue? (what I really mean, is only maintain a queue of size 1)

@rdeits
Copy link
Owner Author

@rdeits rdeits commented on 92f939f Apr 22, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, the meshcat-python implementation is a bit different (with an explicit server speaking ZMQ to the clients and websockets to the browser). Is the goal to make the draw commands block until they are actually received by the browser?

@peteflorence
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey Robin!
The goal is to make it so that a queue of stuff to visualize doesn't build up, making the visualization lag behind the "latest" messages.
For example if I visualize thing A (with hundreds of things in sequence), then thing B (also hundreds of things in sequence),
then I find myself manually tuning a time.sleep() after sending off thing A so that it can finish visualizing thing A before visualizing thing B. Otherwise it can mess up the timing of thing B.

Options:

  • One thing that could help yes would be a blocking call.
  • The other route I was thinking was just to make the queue of messages only be of length 1. For example in ROS in a subscriber you can set the queue size to be 1, in which case it will always process the latest message, even if it's lagging behind. You get more skipping, but you get more "up to date" / realtime visualizations.
    I guess this queue = 1 thing would be on the .js server side, rather than python/julia clients?
    No worries if you don't have time to think through this! I'm a very happy MeshCat user.

Please sign in to comment.