[mythtv] [mythtv-commits] Ticket #8863: 'myth_system' doesn't disable lirc input when running subprocesses

Gavin Hurlbut gjhurlbu at gmail.com
Tue Sep 7 18:49:47 UTC 2010


>
>  Unless something has changed the problem with sending an event is you need
>  to make sure the event has been received and processed before starting the
>  external process because myth_system() is supposed to block the main
>  thread while the external process is running unless the
>  MYTH_SYSTEM_DONT_BLOCK_PARENT flag is used. You can use dispatchNow() but
>  that is depreciated.
>

The code I started from didn't have that actual heuristic attached to
MYTH_SYSTEM_DONT_BLOCK_PARENT.  It always blocked the parent, but used this
as a way to choose to block in a usleep rather than waitpid.  As this is now
done in a central QThread, and that thread always blocks on the usleep, this
flag no longer has that affect at all even.  I am about to rename it to its
actual current function, which is to control disabling the drawing in the
main window thread.  Maybe we are talking about the same thing?

Rest assured.  The calling thread is blocked, and the support to disable the
drawing is already done with an event.  We use sendEvent to make it bypass
the queue (according to my understanding of the comment already in the
code), and I will be using the same methodology for the input device locks
events.

This code has been active in trunk for over a week now, and I have not yet
heard of anything that seems to be a bug in its functionality.  The only one
was this broken lirc/js menu locking, which was inadvertently broken by the
move of myth_system into libmythdb.  OK, and some Windows build breakage
(sorry again!)

I have a patch ready to stress-test for this tonight.  It's working in the
"normal" case, but I need to trigger a LIRC locking, and that will take a
bit of research to determine which call will actually trigger it... or to
force the issue.  My backend and frontend are currently running with the
patch in place, and I expect no issues with the "normal" case.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mythtv.org/pipermail/mythtv-dev/attachments/20100907/32d9de04/attachment.htm>


More information about the mythtv-dev mailing list