summaryrefslogtreecommitdiffstats
path: root/Makefile
diff options
context:
space:
mode:
authorGravatar Linus Torvalds <torvalds@linux-foundation.org>2011-09-15 22:58:02 -0700
committerGravatar Linus Torvalds <torvalds@linux-foundation.org>2011-09-15 22:58:02 -0700
commit8c18add46b2cc0cdfc8c1095916bce81fbde1f1f (patch)
tree75da8196fc70d20662cb59d89d070e0c97c5cfdf /Makefile
parent5804c2970eaaf0215b9862f767cf7aa745083744 (diff)
downloadsubsurface-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 'Makefile')
-rw-r--r--Makefile2
1 files changed, 1 insertions, 1 deletions
diff --git a/Makefile b/Makefile
index fb84494fc..2f24eb7de 100644
--- a/Makefile
+++ b/Makefile
@@ -12,7 +12,7 @@ subsurface: $(OBJS)
$(CC) $(LDFLAGS) -o subsurface $(OBJS) \
`xml2-config --libs` \
`pkg-config --libs gtk+-2.0 glib-2.0 gconf-2.0` \
- $(LIBDIVECOMPUTERARCHIVE)
+ $(LIBDIVECOMPUTERARCHIVE) -lpthread
parse-xml.o: parse-xml.c dive.h
$(CC) $(CFLAGS) `pkg-config --cflags glib-2.0` -c `xml2-config --cflags` parse-xml.c