Question #272154 on Sikuli changed: https://answers.launchpad.net/sikuli/+question/272154
Glowing Crystalline Entity posted a new comment: Well, in this case, you scroll/wheel 10 steps, then wait for a second (or even a tenth), then scroll/wheel again... and it's very jerky. That's maybe just aesthetic, but if you were actually doing a calculation for example, you'd be slowing down your computation speed. (... or a data transfer) So you're right, that for interrupting to make sense, you need to be busy with something else, and in this case you're busy wheeling the mouse. So what I had initially implicitly imagined, was that I'd start one thread that would just wheel away without end, and another that would watch for the condition by which I wanted to stop, and then signal the first thread to do so -- at which point it could terminate or continue with other work. Of course this sort of architecture only makes sense in a multi- processor (as opposed to merely multi-threaded) environment... but almost every computer these days is such. But the possibility, as you mention, of polling being hidden behind an API is what I meant by "... resolves to some lower-level polling anyway...". A handler isn't really a point of interruption -- it necessarily can't run on a thread that's busy with other work, or in general know to interrupt/stop such a thread -- but it is an opportunity for the API user to create their own interrupt, if that's what they want to do. The reasons to do so might be those above, and I'm sure there are others. -- You received this question notification because your team Sikuli Drivers is an answer contact for Sikuli. _______________________________________________ Mailing list: https://launchpad.net/~sikuli-driver Post to : [email protected] Unsubscribe : https://launchpad.net/~sikuli-driver More help : https://help.launchpad.net/ListHelp
