ThreadConstrain

[AlexRast]

Fixes issue with edge generation and allows constraining number of threads per core

[AlexRast]

There is a problem with making ThreadConstrain merged with Mark's commit. His is on softswitch_addresses, whilst ThreadConstrain is branched off development. Meanwhile, the additional feature was tested using the neural simulation xmls (where it works, as a branch of development). But if you use the same feature on ThreadConstrain, although the constraints mechanism works, the neural simulation itself doesn't, failing in the same way we have seen earlier with softswitch_addresses, namely, that no messages are ever issued from the source device. I tried adding in the EdgeStatePropsFix as well but that didn't change the behaviour. So there is another bug somewhere in softswitch_addresses which I don't want to get pushed into development. Thoughts?

[mvousden]

There is a problem with making ThreadConstrain merged with Mark's commit. His is on softswitch_addresses, whilst ThreadConstrain is branched off development. Meanwhile, the additional feature was tested using the neural simulation xmls (where it works, as a branch of development). But if you use the same feature on ThreadConstrain, although the constraints mechanism works, the neural simulation itself doesn't, failing in the same way we have seen earlier with softswitch_addresses, namely, that no messages are ever issued from the source device. I tried adding in the EdgeStatePropsFix as well but that didn't change the behaviour. So there is another bug somewhere in softswitch_addresses which I don't want to get pushed into development. Thoughts?

The change to use HostLink::go instead of HostLink::goOne here resolved an issue where the mothership would not pass through the softswitch initialisation barrier. This suggests to me that the source of the issue exists somewhere in the interplay between the mothership and the softswitch, as opposed to when cores are loaded by the mothership.

To clarify, my understanding is that both of these are true:

• The neural simulation works on the softswitch_addresses branch, on the development branch, and on the ThreadConstrain branch.
• The neural simulation does not work when these three are merged together.

If all of the above is true, one would need to analyse the instrumentation data for softswitches that hold "silent cores", to establish whether packets are actually being sent. From there, one would need to analyse the control flow using the UART debugging output to verify that:

• Cores are being loaded correctly, and their runtime attributes match those given in the generated source, and that
• Appropriate handlers from devices are actually being called (though instrumentation can also do this).

@AlexRast, if you would be so kind as to drop a neural simulation example (and a generator, if you have one) into the orchestrator-examples repository (https://github.com/poetsii/orchestrator_examples), that would help us reproduce the problem in the new year. That way, we can resolve the issue, and octopus the branches together appropriately.

[mvousden]

See #151