Types for device properties and state only available within that devices handlers #232
Comments
|
Perhaps I'm misunderstanding, but could one just define a type in the |
You used to have to do this in our "v2" Softswitch for the local device shared code and it was a pain. When we (you @DrongoTheDog and I) were discussing struct scoping, we decided that it made sense to make the device-level structs available in the device's shared code but that making them available at the global level could cause issues. Unfortunately I can't remember what the issues we identified were, but compile time springs to mind.
Is this just for sizing? or are there other "legitimate" reasons you can see for devices (and by extension supervisors) to have access to the struct declarations for all device types? I guess that a potential fix is to emit a general types header (rather than just a message types header) that includes all of the extra structs. However, where does this stop? Does it include all of the edge props/state structs as well? |
|
Yes, you could create a custom type in You could replicate the structure of a message type, and then make sure you kept the There is also a worry that an implementation might decide to lay out the types (I notice that the orchestrator doesn't emit pragma pack 1. I guess this is less of Also, if you take the approach of having two distinct types you need to either memcpy So the well-known type-name is there to allow handlers to refer to the types
I assume by CDATA section you mean something like a MessageType or State element? In the v3 XML there was more support for custom type instances through typedefs, |
It's done in various other implementations (at least two simulators in graph_schema, poets_eco_system, and the reference When exposed as global type names, you get
It's mainly todo with sizing, and for things like static assertions. It's useful to check at compile-time It was more useful with the V3 support for typedefs, but a few of those use-cases have disappeared In cases where you are working around the lack of expressiveness, it is still useful to be able to
Yes, the spec expects named types for edge properties and state too: |
heliosfa
added
bug
This follows on from #231.
This was done on development_dt10_branch (fd0196a), as otherwise I
cant get through parsing through to compilation. The branch has the current 1.0.0-alpha merged in.
Some existing graphs refer to various global types in order to work out things like the maximum
size of things at compile-time. Also, within the global SharedCode it might refer to any of the
state or properties of devices.
At the moment it looks like only the types for the device currently being compiled are emitted, which breaks
applications that use multiple device types and refer to those types from across handlers.
For example, this is used in an APSP implementation to statically work out batch size:
https://github.com/POETSII/poets_improvement_proposals/blob/2a355282f3aa3912bdacf4ec50bf25199bdf310d/proposed/PIP-0020/xml/ic/apps/apsp_vec_barrier_150_10.xml#L12-L15
Current behaviour:
Microlog:
The text was updated successfully, but these errors were encountered: