excessive/repetitive calls to jlink dll functions

[diggit]

Many jlink methods have decorator @open_required, @connection_required and more. Each validator asks for the state and it always calls dll function.
Was some form of caching considered?
It would reduce log flood and maybe even lower overhead.

[hkpeprah]

Good question. I'm not sure what the right approach here is. Given there's nothing to stop me as a user from yanking a cable or toggling power off, I think there is value in checking before each command, as the state may have changed in the physical world. Do you find that the overhead is a lot or is it just the logging?

[diggit]

Given there's nothing to stop me as a user from yanking a cable or toggling power off, I think there is value in checking before each command, as the state may have changed in the physical world.

Would not the the dll function call return an error in such case?

I did not do benchmark's so now only the logs.

[hkpeprah]

They would after an attempt. I think we can add an option for this where we skip status checks and just let the calls fall-through. Would that address your use case? Something like skip_status_checks to the constructor.

[diggit]

Thinking about this again - if the dll call fails in a recoverable way (just a error value returned - hopefully a least a bit descriptive error code), then the check is probably done inside the dll too and what is the point to do it manually in pylink then?
(I don't have an access to SDK or it's docs.)