Don't get me wrong, I don't disagree with you. Your suggested approach
definitely crosses all the ts and dots all the is. I just wanted to know whether
there's a problem with simply disabling the port that you are aware of and I'm
not. I'm sure you understand that I, and possibly Érico and others who have
existing drivers with existing cleanup code, have a judgment call to make. Your
suggested approach may be Best Practice in this context, but in general, so is
RAII, and they are not quite aligned. What you're proposing requires changing
the design of the driver such that it can be made defunct and resources released
without actually destroying it. And doing a redesign of a working driver has to
be weighed against simply disabling the port before destroying it, which seems
to work well in practice.
Another thing I'd like to point out is that your proposal moves the
responsibility of preventing the read and write calls to each driver. Which
works, of course. But I find it much more elegant to have these checks further
up the stack. Which, for the case of IOC scan threads which go through asyn
device support that, in turn, calls asynManager's queueRequest method, is
already the case! Don't you think it would make sense to enshrine (and perhaps
improve) this behavior and make life simpler for the drivers? I mean, doing
proper clean up in EPICS is fraught, this could be an opportunity to make things
a little bit better.
Best,
Jure