Live update descriptor

[micahwoodard]

Is your feature request related to a problem? Please describe. View needs a way to know what properties to update during acquisition.

Describe the solution you'd like Create descriptor class to decorate certain classes

Acceptance Criteria

• [ ] create descriptor class
• [ ] create a thread safe implementation

[micahwoodard]

@adamkglaser I've been mulling over how to do this during an acquisition without running the risk of querying a device at the same time and causing a crash. I think creating device specific threading locks for each device would be a good option. I do this in the view ui and then I share these locks with the acquisition ui. We could do something similar for voxel and then create another thread during the acquisition to query through all of the signals we want to keep track of and yield them to the ui to handle. This way we can run something simultaneously to the acquisition to get things like temperature, latest image, stage coordinates etc., but not worry about crashing.

If you don't love that idea, we can also go through and make the drivers thread safe. Here's a quick preview on how to maybe do that. Seems relatively simple although going through every driver may be laborious. The bonus there is that we could be more relaxed about calling devices. However, one major downfall is that it relies on every driver that people use to be thread safe which I think is a bit unrealistic.

Let me know what you think and I can start moving forward with either one or if you have a other ideas let me know

[adamkglaser]

@micahwoodard agreed I think that handling the locks outside of the drivers would be more ideal. Since it would make adding additional drivers simpler? For us and if others added drivers.

If I understand option 1 correctly, this would be coded once and live in the acquisition run() function?

[micahwoodard]

I was thinking the locks would be created in the instrument in the _construct_device function since we are already looping through all of the devices and know what devices share com ports. Since you have to pass in an instrument object anyway into the acquisition, you can share the locks that way. Then, whenever you call a device in the run function you would need to call the corresponding lock. I can start a rough branch of this if you think this would be a good way of approaching?

[adamkglaser]

Ah that makes sense to me. I agree I think this is the most logical implementation.