diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2011-09-15 22:58:02 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2011-09-15 22:58:02 -0700 |
commit | 8c18add46b2cc0cdfc8c1095916bce81fbde1f1f (patch) | |
tree | 75da8196fc70d20662cb59d89d070e0c97c5cfdf /dives/61.xml | |
parent | 5804c2970eaaf0215b9862f767cf7aa745083744 (diff) | |
download | subsurface-8c18add46b2cc0cdfc8c1095916bce81fbde1f1f.tar.gz |
Do libdivecomputer imports in a separate thread
This is the hackiest thing ever, unless you count the previous code that
was even hackier (and just called the gtk main routine at random
places).
The libdivecomputer library is not really set up to be part of the gtk
main loop, and cannot afford (for example) to have lots of mainloop
events while it's parsing. Some dive computers are very timing
sensitive for the communication.
So just start a thread for doing the libdivecomputer stuff, and just
continually call the gtk main loop while that thread is running. I'm
sure we could actually use some gtk signalling thing to make the thread
exit do the right thing, but instead we just poll the status every
100ms.
I did say it was hacky. It does seem to work, though. No more
temporary graying out of the windows when they don't react in a timely
manner because libdivecomputer does some blocking operation.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'dives/61.xml')
0 files changed, 0 insertions, 0 deletions