Hi Derek,
An event loop is basically a while loop that a thread or an app runs to process
various events. In fact, NVDA is event-driven, hence it also comes with an
event loop (called wx.App.MainLoop()). As long as certain event does not occur
(such as shutdown), the event loop will pop messages from a queue and process
it, akin to what you are already doing in your add-on. Also, only one thread at
a time should post (or push) messages to an event queue (that's the queue the
event loop will look at), otherwise you run into an inconsistent behavior from
the event loop thread (I believe it is called race conditions).
Cheers,
Joseph
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of derek riemer
Sent: Friday, July 24, 2015 9:52 AM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] Re: play silence addon
Can you explain what you mean by an event loop? Also do you mean c style
interrupts? I wasn't aware that handling such signals from threads is safe.
Thanks,
Derek
On 7/24/2015 10:35 AM, Joseph Lee wrote:
Hi Derek,
You are attempting to join a queue object, which doesn't make sense from main
thread's point of view unless the queue object supports this. Join is allowed
from the main thread when it wishes to wait until something useful happens
such as workers finishing their jobs.
A few more things:
* Is self.queue really necessary? From what I can tell, it isn't.
* Instead of using a queue, I think it might be better to use threading.Event
or threading.Condition variables to let the main thread alert the worker to
do something.
* If you are not ready to explore events or condition variables yet, you
could try using a global yet private flag (such as _message) that the worker
thread can check in a while loop. For example:
_message = "run"
Then the worker will say:
while _message != "die":
# do its work
Then all that needs to be done in the global plugin's terminate method is to
set _message to "die", after which the worker can respond by setting _message
to None. The body of the loop will resemble C++'s switch statement
(if/elif/else) - the thread will do something based on the contents of that
flag.
* I think it might be better to come up with an interrupt-driven or an event
loop-based solution, as the solution right now is continuous polling which
eats valuable battery power (if not designed well).
In multithreading (or for that matter, in parallel programming), it is
important to remind yourself as to who is in charge. The main thread alone is
in charge of overall program execution, more so if GUI's are involved.
Sometimes, one or more worker threads can be designated as assistants to the
main thread in controlling parallel execution. Only the thread that spawned
worker threads can wait for other threads to do its job (this is the join
method), and if something goes wrong, the main thread receives most of the
blame.
Hope this helps.
Cheers,
Joseph
-----Original Message-----
From: nvda-addons-bounce@xxxxxxxxxxxxx
[mailto:nvda-addons-bounce@xxxxxxxxxxxxx] On Behalf Of derek riemer
Sent: Friday, July 24, 2015 7:37 AM
To: nvda-addons@xxxxxxxxxxxxx
Subject: [nvda-addons] play silence addon
I am writing that play silence addon. I have found a computer that exibits
the behavior that the one person mentioned (if you know who I am talking
about, tell me, i don't remember who that was). I almost have it working. The
only problem is that the addon doesn't quite work at this point because it
locks up when waiting for nvda to play other sounds like the error sound or
exit sound.
If anyone would like to take a stab at debugging it, or recommend another way
to solve the problem that would be great. Currently i start a worker thread
that plays silence constantly. It listens in a queue for the "die",. "wait",
and "resume" messages, and if it receives the wait message it temperarily
stops playing silence with nvwave, so that nvwave can play another audio
file. When it receives resume it starts playing silence again. When it
receives die it exits the whole thread (This happens when nvda exits. I don't
know much at all about parallel programming so I don't know if this is the
correct way to do this. Nvda seems to freeze when i call queue.join in a
monkeypatched version of playWaveFile. This is so that I can wait until the
other thread stops playing silence and I can safely use nvwave.
It locks nvda into a scarey bind currently and if you don't know what you are
doing it will totally just lock your computer up, so DO NOT USE.
If nvda plays any wave file at all it will just wate forever. The repo
I currently have this in is at
https://bitbucket.org/derek_riemer_/play-scilence
----------------------------------------------------------------
NVDA add-ons: A list to discuss add-on code enhancements and for reporting
bugs.
Community addons are available from: http://addons.nvda-project.org To
send a message to the list: nvda-addons@xxxxxxxxxxxxx To change your
list settings/unsubscribe: //www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx
----------------------------------------------------------------
NVDA add-ons: A list to discuss add-on code enhancements and for reporting
bugs.
Community addons are available from: http://addons.nvda-project.org To
send a message to the list: nvda-addons@xxxxxxxxxxxxx To change your
list settings/unsubscribe: //www.freelists.org/list/nvda-addons
To contact list moderators: nvda-addons-moderators@xxxxxxxxxxxxx
