diff options
| author |  Joey Hess <joey@kitenet.net> | 2012-10-25 15:30:49 -0400 |
|---|---|---|
| committer | Joey Hess <joey@kitenet.net> | 2012-10-25 15:47:27 -0400 |
| commit | d0268981b5411edf812bef00b8d08801e0e75fe9 (patch) | |
| tree | e6f89de71eb244e7192e7a27a5b4eb87cfb87622 /Assistant/Threads/PushNotifier.hs | |
| parent | 7e141b473f8225bc64769e57fd08722532d5ea94 (diff) | |
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.
Diffstat (limited to 'Assistant/Threads/PushNotifier.hs')
| -rw-r--r-- | Assistant/Threads/PushNotifier.hs | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/Assistant/Threads/PushNotifier.hs b/Assistant/Threads/PushNotifier.hs index 84fe4952a..088e97ec4 100644 --- a/Assistant/Threads/PushNotifier.hs +++ b/Assistant/Threads/PushNotifier.hs @@ -45,7 +45,7 @@ pushNotifierThread st dstatus pushnotifier = NamedThread thisThread $ do client c jid = runClient server jid (xmppUsername c) (xmppPassword c) $ do void $ bindJID jid s <- getSession - _ <- liftIO $ forkIO $ void $ runXMPP s $ + _ <- liftIO $ forkOS $ void $ runXMPP s $ receivenotifications sendnotifications where |