From d0268981b5411edf812bef00b8d08801e0e75fe9 Mon Sep 17 00:00:00 2001 From: Joey Hess Date: Thu, 25 Oct 2012 15:30:49 -0400 Subject: convert the assistant to use a bound thread for XMPP This *may* solve the segfault I was seeing when the XMPP library called startTLS. My hypothesis is as follows: * TLS is documented (http://www.gnu.org/software/gnutls/manual/gnutls.html#Thread-safety) thread safe, but only when a single thread accesses it. * forkIO threads are not bound to an OS thread, so it was possible for the threaded runtime to run part of the XMPP code on one thread, and then switch to another thread later. So, forkOS, with its bound threads, should be used for the XMPP thread. Since the crash doesn't happen reliably, I am not yet sure about this fix. Note that I kept all the other threads in the assistant unbound, because bound threads have significantly higher overhead. --- Assistant.hs | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'Assistant.hs') diff --git a/Assistant.hs b/Assistant.hs index 7ab9cea51..77790b9c6 100644 --- a/Assistant.hs +++ b/Assistant.hs @@ -223,7 +223,12 @@ startAssistant assistant daemonize webappwaiter = withThreadState $ \st -> do waitForTermination watch a = (True, a) assist a = (False, a) + + {- Each named thread is started in a bound thread. + - (forkOS rather than forkIO). There are not too many, + - and this deals with libraries like gnuTLS that + - require only one thread access them. -} startthread dstatus (watcher, t) - | watcher || assistant = void $ forkIO $ + | watcher || assistant = void $ forkOS $ runNamedThread dstatus t | otherwise = noop -- cgit v1.2.3