Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

doReadTransfer etc. must not be called any more #121

Closed
3 tasks done
killenb opened this issue Apr 7, 2020 · 2 comments
Closed
3 tasks done

doReadTransfer etc. must not be called any more #121

killenb opened this issue Apr 7, 2020 · 2 comments
Assignees
Labels
readyForImplementation This ticket has been moved to the "ready for implementation" area on the MSK software group board selected This ticket has been selected for the MSK software group board umbrellaChild Child ticked generated from an umbrella ticket

Comments

@killenb
Copy link
Member

killenb commented Apr 7, 2020

Child of ChimeraTK/ApplicationCore#123
Depends on #117

All code which is executing the read and write sub-steps separately must not call doXxxTransferYyy directly any more, but call xxxTransferYyy (e.g. readTransferLatest() instead of doReadTransferLatest()).

This concerns all decorator-like Accessor-Implementations, for instance (list not complete)

  • LNMBackendBitAccessor
  • LNMBackendChannelAccessor
  • NDRegisterAccessorDecorator

The TransferGroup is done in a separate ticket (#120)

  • Find all places in DeviceAccess where a doXxxTransferYyy function is used and replace it with xxxTransferYyy (except for the TransferGroup)
  • List all the classes you found in this ticket
  • Create a follow-up ticket for each of them that a test for this functionality should be written
@killenb killenb added umbrellaChild Child ticked generated from an umbrella ticket selected This ticket has been selected for the MSK software group board readyForImplementation This ticket has been moved to the "ready for implementation" area on the MSK software group board labels Apr 7, 2020
@mhier mhier self-assigned this Apr 9, 2020
@mhier
Copy link
Member

mhier commented Apr 9, 2020

Does it hurt if I fix this aspect in the TransferGroup already?

mhier added a commit that referenced this issue Apr 9, 2020
…e asynchronous thread

This probably would lead to std::terminate. The exception is propagated through the queue and will be thrown in postRead().
@mhier
Copy link
Member

mhier commented Apr 9, 2020

Only found the problem in TransferGroup, all the others were already fixed in #117. Since the TransferGroup already has the follow-up ticket (#120) I think there is no follow up ticket to write.

@mhier mhier closed this as completed Apr 9, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
readyForImplementation This ticket has been moved to the "ready for implementation" area on the MSK software group board selected This ticket has been selected for the MSK software group board umbrellaChild Child ticked generated from an umbrella ticket
Projects
None yet
Development

No branches or pull requests

2 participants