Opened 16 years ago
Closed 16 years ago
Last modified 16 years ago
#4376 closed task (fixed)
Handle keypresses in the main UI thread (refs #4230 and #4085)
Reported by: | Owned by: | danielk | |
---|---|---|---|
Priority: | minor | Milestone: | 0.21 |
Component: | mythtv | Version: | head |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
Handling keypresses outside of main UI leads to events and dialogs being created on different threads and not being handled properly. On Windows, this leads to:
a) mythfrontend deadlocks when trying to switch to program guide from livetv. b) muteTimer never fires, sound stays muted after any seek or channel change.
The overhead associated with creating separate threads the way it is currently being done seems to be unnecessary, but I could be missing something. The proposed patch processes keypresses on the main thread, which fixes both problems.
If the patch cannot be accepted as is, we need to look for a similar solution, as having a single UI thread is the only way to have application behave predictably on Windows.
Attachments (3)
Change History (15)
Changed 16 years ago by
Attachment: | threading.patch added |
---|
comment:1 Changed 16 years ago by
Owner: | changed from Isaac Richards to danielk |
---|---|
Status: | new → assigned |
comment:2 Changed 16 years ago by
Milestone: | 0.21 → unknown |
---|---|
Type: | patch → task |
comment:3 Changed 16 years ago by
Ok, how about this: process events as usual in the RunTV() thread, but send some of the requests (EPG and unmute timer) back to the main thread for actual processing. This looks a lot cleaner to me compared to even what we currently have, and it solves this critical Win32 issue. See tv_play.patch.
Changed 16 years ago by
Attachment: | tv_play.patch added |
---|
comment:4 Changed 16 years ago by
Milestone: | unknown → 0.21 |
---|
That sounds good in theory, I'll review the patch when I get a chance.
comment:5 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
comment:6 Changed 16 years ago by
Resolution: | fixed |
---|---|
Status: | closed → new |
Changed 16 years ago by
Attachment: | ticket_4376_causing_embedded_playbackbox_to_hang.diff added |
---|
comment:7 Changed 16 years ago by
changeset[15630] causes embedded playbackbox to hang. attached patch leaves embedded playbackbox as a thread and also cleans up the function pointer associated with it.
comment:8 Changed 16 years ago by
Can someone confirm if this breaks "Jump to Program" from within LiveTV? It seems to hang while starting.
Thanks, Mark.
comment:9 Changed 16 years ago by
(In [15717]) Refs #4376. revert back to using new thread for call to embed tv player in the playerbox container since [15630] causes a hang when trying to use this feature. not sure if this breaks MINGW compability. also made some minor changes the function pointer calls associated with it. did this change cause I plan to soon add ability to view upcoming schedule list while watching a show.
comment:10 Changed 16 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Andrei, if Stanley's revert/fix caused a problem with MINGW please reopen.
comment:11 Changed 16 years ago by
(In [15745]) Fix the call to RunProgramFind?() in tv_play.cpp. [15630] should have changed the call to this as well when the event handling was changed. This should fix the frontend hanging with recent SVN when you tried to popup the Program Finder while watching a recording.
References #4376.
Key and network control commands both have to be processed in the RunTV() thread for TV class to remain in a consistent state.
I'm sure MS Windows allows for multi-threaded GUIapplications, there are probably just some additional limitations. We need to trace the reason for the deadlock when switching from the program guide from LiveTV, and QTimer can be replaced with something that works on MS Windows. QTimer in particular causes its own thread-safety problems in Linux and OS X anyway.