Open trentgill opened 5 years ago
I think what we'd want is exclusive access to a single crow, not a necessarily a single instance of druid (I can have two crows and might want to connect to both of them with a separate druid instance for example).
tldr; This issue for me is about the confusing situation where 2 instances of druid connect to the same serial port but only one of them receives responses.
// Below is some ramblings about the difficulties of supporting multiple simultaneous crows.
Having 2 crows that you want to speak to with independent druid sessions seems like an incredibly niche use-case to me. I think this is a context where we can be opinionated about how this should be done, rather than make everything possible. We should choose one of the following (or others?):
My inclination is that there's a bunch of way-more mainstream features we can add than worrying about the implementation of 3 or 4 above. In particular, both of those options require adding user-controls for choosing serial ports / devices which feels like it will be even more confusing for novice users.
witnessed a real-world pre-show debug that eventually found this as the culprit. on macos. symptom was everything worked, but ^^connected
was being printed over and over
When multiple druids are open connected to the same port there is a race condition which makes it ambiguous where the returned values will appear. This is very confusing for new users when they don't realize they have druid open in a different window.
I've tried to simply set the
exclusive = True
param in theserial.Serial
call in crowlib, but this is even more confusing. The<disconnected>
message never appears in druid, and I'm not sure if it's possible to check why the serial connection failed. If we can test if the port exists but is locked by a different process, then it would be great to print a message "another instance of druid is already open".