standards-proposals
standards-proposals copied to clipboard
codeplaysoftware
CP013: Support dynamic device discovery
There was feedback from Jacksonville that we should start looking into how to support dynamic device discovery, where an execution resource within a system may become available or unavailable during execution.
In order to reliably support this feature there needs to be a guarantee that if a device can become available or unavailable during execution, that this can be handled gracefully. For this reason we should aim to make this feature optional so that implementations which cannot handle dynamic device discovery gracefully can opt to not support it.
Supporting dynamic device discovery would also mean that the system topology may change between one query and another. So there needs to be a way for users to be notified of a change to the system topology through some form of callback mechanism, and there needs to be a way for for users to update the topology information when this happens.
Another option could be to not be specific about whether an execution resource is dynamic or static, but simply have some execution resources to be updated by dynamic device discovery.
Thinking further about how a potential interface for this could look I see two possible ways to do this. Firstly we could have a callback mechanism, where a user provides a callable object, possibly to an execution context, which is then called whenever the system topology is updated. Secondly, we could have a polling mechanism where users would be required to call a free function which would update the system topology information on completion. This function could be blocking or asynchronous.
I prefer the second approach of having a polling mechanism, as it allows users to manage the topology manually, whereas the former approach of having a callback would likely require fixed update points between the execution of tasks or burning a thread to run in the background, both of which could lead to unpredictable performance penalties. I also think that such a polling function should be blocking as making it asynchronous requires potentially taking resources from the topology which you are querying while making it blocking puts the onus of where the polling is performed in the user's control.
I am changing the label to enhancement since this will not be addressed in the paper for RAP18
