Stopping spawned threads when the web session dies?

[thomasjm]

I've been noticing that the threads spawned via "connect" (whenever you visit a comet-enabled page) never get killed. Is it possible to somehow detect when the web page has been closed and cause the thread to die? Otherwise it seems like these threads will pile up forever. Thanks!

[thomasjm]

To give a little more context: I have a very interesting segfault in my Haskell program (!) which appears to be related to kansas-comet. I do the following:

1. In ghci, run my "main" function and Control-C it. Repeat this several times to verify the program doesn't segfault. (The program starts Scotty and calls "connect" on kansas-comet, similar to how the example works. But no Documents have actually been viewed yet.)
2. In the same ghci session, run "main" again and open the kansas-comet page. The page loads fine.
3. Control-C the program.
4. Run "main" one more time and open the kansas-comet page. GHCI itself immediately segfaults. Occasionally it prints the message "pthread lock: Invalid argument" before it dies.

Do you have any idea what this could be about?

[andygill]

Someone will look at this in a bit. We want to get this working before releasing a paper about blank canvas.

[RyanGlScott]

Hm, I'm having trouble reproducing this problem. What setup are you using? I'm using GHC(i) 7.8.4 on 64-bit Linux, and I've tried repeating steps 1-4 using the kansas-comet example on Firefox and Chrome, to no success.

[thomasjm]

Sorry, I made some more progress on this. I found that the segfault was actually unrelated to kansas-comet. It was an issue where Scotty/Warp was failing to die completely when I did the Control-C, and it was holding on to an old, unsafe database handle. Step 4 would trigger an attempt to use the database handle and the segfault. So that's one mystery solved.

It would still be really nice if kansas-comet could detect when clients are going away though. Otherwise I'm going to have to implement my own heartbeat mechanism.

[andygill]

The purpose of kansas-comet is to provide a robust channel between a Haskell server, and a JavaScript client. It makes sense that the comet provide some sort of heatbeat to make the channel robust. We should perhaps revisit the user-facing API to see if this should be exposed somehow - we've not really thought about robustness.

[thomasjm]

Yeah, the client API is a little tricky, especially given that the web_app function may spawn additional threads. For example, in my use-case I have both a "control" and an "update" thread.

Here's a suggestion:

1. In the Options, allow the user to specify a "heartbeat timeout".
2. If the server doesn't hear a heartbeat from the Javascript client for more than the heartbeat timeout, it throws an exception to the web_app thread.

By catching this exception the user can do whatever cleanup they need, including killing child threads. (If they fail to catch the exception and their thread dies by default, so much the better.)

[thomasjm]

Hey @andygill , friendly ping on this issue?

[andygill]

No, we've not looked at it, but with the summer starting, we'll pull into into our summer projects.