client-ghcjs: Merged master + Fix MVar blocking exception #610
Conversation
The Servant.JS Counter example was broken: - `axios` was not completely applied. It now uses `defAxiosOptions` similarly to the `angular` example - `OverloadedStrings` was required, but not included
CaptureAll combinator - take haskell-servant#2
Fix servant-js examples
Contributed by freezeboy in PR haskell-servant#11 - https://github.com/haskell-servant/haskell-servant.github.io/pull/11/files
…rvant-js-docs Add more JS documentation.
…rvant/haskell-servant#581 * Version bump because this changes the API for GetHeaders
…tructions add 'stack setup' command to CONTRIBUTING.md
Fix typo in servant-js README
Uses the fix mentioned by @arianvp in haskell-servant#425. See also haskell-servant#51 (comment) The cause of the issue very is similar to the issue described in this blog post: https://www.fpcomplete.com/blog/2016/06/async-exceptions-stm-deadlocks The main thread creates a waiter, creates an asynchronous callback which is called when the `readyState` of the request changes. When the readyState changes to 4, which means 'request finished', the waiter MVar is put. The main thread takes the MVar and continues to do stuff with the response. The problem is that the `readyState` can change to 4 more than once, for some reason. The second time this happens, the waiter MVar can be put again, since the main thread took it. The main thread, however, won't take it again. After all, it only needed to take the MVar once to know that the request was finished. The third time `readyState` is set to 4, the putMVar would block, causing the following exception to be thrown: ``` thread blocked indefinitely in an MVar operation ``` Since state 4 should really mean that the response is ready, it seems appropriate to decide that all changes of the state to 4 after the initial one can be safely ignored.
|
Terrific, thanks! |
|
Hmm, looking through the code, it's not obvious to me where or how GHCJS is being tested. @soenkehahn any insight? In other news, stack does have binary distributions for GHCJS. Also, a trick I've seen in some GHCJS package (I can't remember which now) to deal the build timing out with cold caches is have a conditional check on the CI script to check whether the cache is cold. If so, only try building part of all the things, and then error out (someone would manually have to restart the build in those cases, or trigger another one with a commit). |
|
I don't think ghcjs is being tested at all. |
|
Ah. Sorry, maybe I wasn't clear. The CI problem I was thinking of was that we still didn't have a good way of testing GHCJS on CI. |
|
I can imagine that being difficult, since you'd want to compile servant-client with both ghc and ghcjs and then perform tests with both of them. |
|
Yeah... On the other hand, releasing something without CI into the wild sounds like a recipe for disaster. We do have servers that we could use though. So we could have something that just runs a cronjob or handles a github hook, without starting from scratch every time. If you tell me how to run the tests locally, I could try to get that setup on my server. |
|
(Don't have time to check right now.) Wasn't there a library for facilitating the definition of github hooks? |
|
@alpmestan yes, this. Of course, we'd be running our own CI service, in essence. That's an unfortunate complication to CI, though if we simply can't get travis or Circle to cut it, one I'm okay with. |
|
If travis can deal with ghcjs, it'll probably doable when the ghcjs client is separated from servant-client. |
|
What do you mean separated? I thought from previous discussion the idea was a separate package (rather than a flag), but I imagined the codebase being the same. @FPtje any chance you'll be in London for Haskell exchange? If so, we could try to figure out CI there together (@arianvp will also be there) |
|
Yes, I mean having one |
|
Sadly, I won't be in London, by the way. |
|
A few of us are in London, and are talking about this. On Saturday we're Sorry this is all a bit slow and a bit of a drag, but thanks for picking it
|
|
@dmjio pointed out https://docs.travis-ci.com/user/languages/nix - we could On Wed, Oct 5, 2016 at 7:03 PM, Julian Arni jkarni@gmail.com wrote:
|
|
That looks cool. I did not know Travis could build nix expressions! We already build nix expressions for all our repo's right? We can just adapt those to use ghcjs instead |
|
Hey, I haven't heard from this for a while. Have there been any updates? |
|
@FPtje , I got some more time to work on Servant again (scriptie was taking its toll ;P ), interested in grabbing a coffee soon? |
|
@arianvp Sounds like a plan! I've sent you an email. |
As discussed in #51 (comment) and #609.
This pull request contains a merge commit rather than a rebase. It also contains the fix for the following exception, which is thrown after every request: