thanks! after looking at this more closely i think we should fix it in hidapi, per this comment, instead of here. the reason is that with this change we open the door to other multithreaded programming errors, some of which may be difficult to catch, whereas deadlock is easy to spot and fix with a backtrace. i think it is reasonable, in fact desirable, to continue to enforce that a tick in the language does not occur while interpreting command-line code.

our fork of hidapi, which you should submit a PR against directly, is here: https://github.com/supercollider/hidapi

as far as i know the signal11 repo is unmaintained now.

Brian, thank you for your consideration and comments.



My original intention was to fix hidapi, but as time passed it seemed worthwhile to investigate other solutions.

This PR seemed like a good approach when trylock worked and found it used in older code, esp. doClockTask method from scapp (cocoa tick equivalent).

However, I agree with your concern, and think changing a critical code path to fix an edge case is probably not worthwhile.

Could it make sense to comment point of deadlock?

Maybe make design a little more apparent.

e.g.

void LangClient::tick() {
    double secs;


    lock();
    // deadlock here indicates behaviour which likely should be avoided.
    // e.g. calling qt event loop from primitive.

    bool haveNext = tickLocked(&secs);
    unlock();

Could it make sense to comment point of deadlock?

Maybe make design a little more apparent.

yeah! that would be really helpful actually.

Is this pull request okay, or shall I make a new one?

@gurk no new PR needed, i'll merge this as is. and also edit the PR title so it accurately reflects the purpose. thanks!