Consider adding onDeviceUnloaded callback?

[tlambert03]

In pymmcore-widgets (and other event-driven stuff on the python side), I don't believe we currently have a good way to know if a device has been unloaded (so as to disable certain features in the GUI). We currently use onSystemConfigurationLoaded as a sort of proxy for this, since it often means a device has been both unloaded and reloaded... but it's not quite accurate, and would miss cases in which a device is unloaded but not reloaded

@marktsuchida, what do you think about this?

[marktsuchida]

Yes! Related: #149, #163(, #594).

I'm leaning toward "device did become available" and "device will become unavailable" (or Qt-style "about to become") events, the former being fired upon successful initialization. (Do we also want an event for "device loaded" (but not initialized) and "device unloaded" (even if never initialized)?)

What are the threading requirements, if any? Is it safe to emit these events on the same thread as the call (into MMCore) that causes the state change? What if they are sometimes emitted from a different thread (such as used for parallel initialization)?

(Probably we should either always emit synchronously or always emit asynchronously, though that is not a rule followed by our callbacks in general.)

[tlambert03]

ah right of course... 😂 shall we close this as a duplicate?

(Do we also want an event for "device loaded" (but not initialized) and "device unloaded" (even if never initialized)?)

I'm not opposed. It's all potentially useful, and it's nice to give the application the choice.

Is it safe to emit these events on the same thread as the call (into MMCore) that causes the state change?

it's a good question, however, i think it's largely an application side question right? As long as the core side uses mutexes for things that absolutely should not be called without a lock, then i don't think it needs to worry about who is listening to the emissions. Applications should all have mechanisms to receive events on one thread and queue the reaction for another thread if it's critical for callback. (or am I missing something that might be important on the core side?)

(Probably we should either always emit synchronously or always emit asynchronously, though that is not a rule followed by our callbacks in general.)

I agree... and I think I see. I need to look closer at all the places where callbacks get invoked (cause it can even be from the device in a thread right?)

[marktsuchida]

Let's continue here regarding events for individual devices and keep #594 for event(s) related to config file loading/unloading.

Actually we need different names, because "available" may be confused with its static sense in getAvailableDevices(). Maybe "device did initialize" and "device will shut down"?

Thinking more about threading:

For new events that we add, I think we really should guarantee always-sync or always-async, because otherwise apps might make the wrong assumption and break in ways that are hard to reproduce reliably. We probably have such problems lurking for some of the existing callbacks.

For the "device will shut down" event, we need to issue it synchronously, because the Core needs to wait for the app to finish its cleanup (= stop monitoring said device) before proceeding. Weird things might happen if the app, in the callback, tries to re-unload the same device, or another device that is already slated for unloading in the original call into the Core, but the Core can detect and reject these cases, and there's probably no other good way.

For the "device did initialize" event, I think we first need to answer a different question, which is how to emit the events during config loading.

• Option 1: Emit as soon as each device is initialized
  • Requires callback to be async for the ParallelDeviceInitialization case, and therefore always async
  • Allows app to interfere with devices during config loading, which can diminish reproducibility of config loading and make troubleshooting harder (all the more so if async), though apps could try to implement a "safe" mode
  • If async, app needs to deal with the case of initialization failure of device N, upon which devices 0 through N - 1 are immediately unloaded. So by the time UI elements start fetching values from devices, those devices may no longer be there.
  • (Edited to add:) It's probably better if the app sees the devices after the System-Startup preset is applied.
• Option 2: Emit for all devices at the end of config loading
  • None of the above problems
  • A (slight) downside is that the app cannot initialize its UI in parallel to the rest of config loading

So if we're okay with option 2, then it can probably work with either a sync or async callback (but probably we want sync, to be consistent with the paired "device will shut down").

Any thoughts? Of course we could go forward with just the "will shut down" event (which is the title of this issue!) and work on the "did initialize" later. And I think I'll get onto implementing #594 before tackling this one, because that one is a good idea regardless.

[tlambert03]

Maybe "device did initialize" and "device will shut down"?

👍

I think we really should guarantee always-sync or always-async

yeah, and sync really is the easier one to deal with. So if willShutDown always needs to be sync, then it makes sense to at least try to make everything sync.

how to emit the events during config loading.

One thing I often wish I had done later when deciding on events to emit is to use sets or lists if i ever think I might want to round up a bunch of events and only deal with the callback after they are all done. So, one possibility here is have a devicesDidInitialize (plural) and have the signature be:

successful = [...]
failed = [...]
devicesDidInitialize.emit(successful, failed)

in the case of loadSystemConfiguration (or initializeAllDevices), that could come after all devices were loaded and initialized, using the DeviceInitializationState to assign devices into the two groups.

A (slight) downside is that the app cannot initialize its UI in parallel to the rest of config loading

i'm not too worried about that. UI initialization is generally not so slow, and the system is generally not that "useable" in the intermediate phase.

so, in summary. I'm in favor of:

deviceWillShutdown(device)
# or
devicesWillShutdown(list_of_devices)

devicesDidInitialize(successful, failed)

[gselzer]

One thing I often wish I had done later when deciding on events to emit is to use sets or lists if i ever think I might want to round up a bunch of events and only deal with the callback after they are all done. So, one possibility here is have a devicesDidInitialize (plural) and have the signature be:

Yes, this is nice. I like both taking lists, since those lists could always have one element anyways

I think we really should guarantee always-sync or always-async,

I like always-sync

[marktsuchida]

Bunching into a single event is absolutely the way to go; great idea, thanks! For will-shutdown, too, the plural form will make more sense.

[marktsuchida]

@tlambert03 Something I missed earlier: do you think we really need the failed list for devicesDidInitialize()? I think 99% of the time listeners (device control widgets, etc.) don't need to hear about devices that never came online, and that initialization errors should be handled by whoever called into the Core to initialize the device(s).

[tlambert03]

Nope, just included for completeness... but not necessary

[marktsuchida]

Separate note, something to probably put into the documentation of devicesDidInitialize(): there may be devices that are not immediately "usable" right after initialization, but do become usable later (for example after further configuration of post-init properties, such as by System-Startup).