Comment 21 for bug 1553804

On 11/28/2016 10:03 AM, Maciej Sumiński wrote:
> Now I wonder how to backport the fix to the 4.0 branch. The PNS router
> creates its own internal data model when it is launched. If the data is
> modified somewhere else (e.g. track clean up process), the PNS model
> becomes stale and inevitably leads to a crash.

Does the PNS router actually have to create it's own separate internal
data model? Can this data model be moved into the BOARD object? This
seems to be the primary design flaw. Using message passing or callbacks
seems more complicated than necessary.

>
> The current fix relies on the BOARD_COMMIT mechanism which sends a
> message notifying all potentially interested tools that the model has
> changed. It is done every time there is a change occurring, so the fix
> ought to be universal. (BTW. to be replaced with observer in the near
> future).
>
> The 4.0 branch does not have BOARD_COMMIT, hence the most trivial
> solution is to add the notification in every place where the model may
> be changed in the background. In the legacy canvas, I see the routing
> tool is simply deactivated when the Track/Via clean up dialog is
> invoked, perhaps that is the way to go. Still, I guess it fixes only
> this particular case and not the root cause.
>

Disabling every tool that can corrupt the PNS router data is going to be
ugly. Every time someone adds new tool they will have to know if they
could potentially corrupt the PNS data. This will create lots of
opportunities to get it wrong. I'm OK with disabling tools in the
stable 4 branch. In the development branch, we should make sure we have
a better solution.