You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 10, 2020. It is now read-only.
Update: This task may actually have been repaired in the course of attempting to solve [Bug] Block Destroy Hypothesis #65 because we removed some unnecessary calls to functions that might have tried to notify the OAC of the update
We have used this issue to track & managed to cut down on race conditions, in most places with logic and in one or two places with hacks (we delayed 1 sec, and labeled it with a TODO)
It may also help to add some some logic to the message system to delay in sending some messages until after some important initialization ones have fired. For example it will make sense to hold all terrain altering messages until the finalized terrain perception message has been sent.
The text was updated successfully, but these errors were encountered:
In general, it is bad form for the sender to try to make up for deficiencies in the receiver. Inn this case, it sounds like all terrain-altering messages should go into a single terrain queue, and be processed in order, one at a time. I mention queues because these have the built-in locking that guarantees a first-in, first-out order. If you don't use aa queue, then you shoul use some ad-hoc lock so that no new messages are handled until terrain init releases the message.
Also: keep in mind that the long-term strategy is to switch to ROS for messaging. whatever fixes are applied today, they should still be valid after some future move to ROS.
(This does beg the question: are there any projects anywhere that add ROS to game-worlds?)
The only other thing I could find basically implied that gazebo is coming along nicely, and that if we wait patiently, it might turn into a game engine someday in the future ...
Spydrouge
changed the title
[Bug] Terrain Perception must finalize before other messages are sent
[Task] Terrain Perception must finalize before other messages are sent
Dec 9, 2014
Spydrouge
changed the title
[Task] Terrain Perception must finalize before other messages are sent
[Task] Terrain Perception should finalize before other messages are sent
Dec 9, 2014
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We have used this issue to track & managed to cut down on race conditions, in most places with logic and in one or two places with hacks (we delayed 1 sec, and labeled it with a TODO)
It may also help to add some some logic to the message system to delay in sending some messages until after some important initialization ones have fired. For example it will make sense to hold all terrain altering messages until the finalized terrain perception message has been sent.
The text was updated successfully, but these errors were encountered: