[nvda-addons] Re: play silence addon

  • From: derek riemer <driemer.riemer@xxxxxxxxx>
  • To: nvda-addons@xxxxxxxxxxxxx
  • Date: Fri, 24 Jul 2015 10:51:31 -0600

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

----------------------------------------------------------------
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

Other related posts: