sikuli-driver team mailing list archive

[Glowing Crystalline Entity <question272154@xxxxxxxxxxxxxxxxxxxxx>]

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.