@@ -230,8 +230,6 @@ As a consequence a copy has to be created whenever the data is written to the de
- Step 2.3.5 is currently being set before initialisationHandlers and writeAfterOpen.
- Check the comment in Device.h about writeAfterOpen(). 'This is used to write constant feeders to the device.'
- Check the documentation of DataValidity. ...'Note that if the data is distributed through a triggered FanOut....'
- Data validity is currently propagated through the "owner", which conceptually does not always work. A DataValidityPropagationExecutor needs to be introduced and used at the correct places.
...
...
@@ -239,7 +237,7 @@ As a consequence a copy has to be created whenever the data is written to the de
- Comment to 1.g: recovery accessors are not optional at the moment.
- i.c Currently data is transported even if the "value after construction" is still in.
- 1.i ThreadedFanout and TriggerFanout do not use non-blocking write because it does not exist yet
- 1.i, 6 ThreadedFanout and TriggerFanout do not use non-blocking write because it does not exist yet
- 1.j, 2.5.3 Not implemented like that. The first read blocks, and a special mechanism to propagate the flags is triggered only in the next module.
- 2.3 The device module has a special "first opening" sequence. This is not necessary any more. The "writeAfterOpen" list is obsolete. You can always use the recovery accessors.
...
...
@@ -247,7 +245,6 @@ As a consequence a copy has to be created whenever the data is written to the de
- 2.4.1.1 Write probably re-executed after recovery. This should not happen because the recovery accessor has already done it.
- 2.5.3 The non-blocking read functions always block on exceptions. They should not (only if there is no initial value).
- 2.5.2, 5.1 writeWithoutErrorBlocking is not implemented yet
- 1.i is not implemented
- Asyncronous reads are not working with the current implementation, incl. readAny.
- 3. DeviceAccess : RegisterAccessors throw in doReadTransfer now.
...
...
@@ -257,8 +254,6 @@ As a consequence a copy has to be created whenever the data is written to the de
- 5.2.1 Exceptions are caught in doXxxTransfer instead of doPostXxx.
- 5.3.1.2, 5.3.2.1 Decoration of doXxxTransfer does not accquire the lock (which does not even exist yet, see 4.2.3)
- 6. TriggerFanout and ThreadedFanout use blocking write (non-blocking function does noexist, see 5.1
