Update libuv to v1.x

[hcorrada]

There are some niceties in v1 of libuv that may help daemonizing and error handling. Before I maybe dive in on seeing what it would take to migrate, I thought I should ask if you guys were thinking about it and had started to look into it.

[actsasflinn]

I did a first pass to update libuv to 1.4.2 and http-parser to 2.4.2. Libuv API changed slightly and was updated accordingly also build seems to have changed since <1.x days. Not sure if my change is the best way to accommodate, feedback welcome.

Here for just libuv
https://github.com/actsasflinn/httpuv/tree/libuv-1.4.2
or here for both
https://github.com/actsasflinn/httpuv/tree/http-parser-2.4.2

[hcorrada]

Thanks @actsasflinn! I've pulled your repo and tested briefly. So far so good. Also tested the POSIX implementation of daemonization and it seems to be working. Unfortunately, I couldn't get this version to compile on Windows. Any ideas?

[actsasflinn]

Yes, likely has to do with configure script for libuv. I'll start up my windows vm tonight and check it out.

On Mar 16, 2015, at 9:16 AM, hcorrada [email protected] wrote:

Thanks @actsasflinn! I've pulled your repo and tested briefly. So far so good. Also tested the POSIX implementation of daemonization and it seems to be working. Unfortunately, I couldn't get this version to compile on Windows. Any ideas?

—
Reply to this email directly or view it on GitHub.

[actsasflinn]

I tried a few things last night to address Windows. Libuv seems to build ok via Cygwin but build via rtools was a no go. I'll keep plugging away on this.

On Mar 16, 2015, at 9:16 AM, hcorrada [email protected] wrote:

Thanks @actsasflinn! I've pulled your repo and tested briefly. So far so good. Also tested the POSIX implementation of daemonization and it seems to be working. Unfortunately, I couldn't get this version to compile on Windows. Any ideas?

—
Reply to this email directly or view it on GitHub.

[hcorrada]

Txs! I'll try to take a look as well

[actsasflinn]

When I try to force mingw I'm a step closer on windows. However it looks like the version of rtools I'm testing with has an issue with mingw which seems to be fixed in a newer version. See here: http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/5953

diff --git a/src/Makevars.win b/src/Makevars.win
index 40a4955..1746bdb 100644
--- a/src/Makevars.win
+++ b/src/Makevars.win
@@ -11,7 +11,7 @@ all: $(SHLIB) libuv/libuv.a http-parser/http_parser.o sha1/sha1.o base64/base64.
 $(SHLIB): libuv/libuv.a http-parser/http_parser.o sha1/sha1.o base64/base64.o

 libuv/libuv.a:
-       make --directory=libuv \
+       make --directory=libuv --file=Makefile.mingw \
                CC="$(CC)" AR="$(AR)" RANLIB="$(RANLIB)" SRCDIR=. PLATFORM=mingw libuv.a

[actsasflinn]

My latest commit seems to work with the dev R and rtools dev packages on Windows.

actsasflinn@2cf7903

[jjallaire]

Note that the current Rtools dev package is in flux (it is going to shortly
revert back to the previous toolchain as the new toolchain has had some
issues successfully building various pieces of CRAN and Bioconductor). If
you do your testing and development against Rtools 3.2 that will
approximate what the final toolchain will look like.

On Tue, Mar 17, 2015 at 9:02 PM, Flinn Mueller [email protected]
wrote:

My latest commit seems to work with the dev R and rtools dev packages on
Windows.

actsasflinn/httpuv@2cf7903
actsasflinn@2cf7903

—
Reply to this email directly or view it on GitHub
#42 (comment).

[elferdo]

Hey guys, any progress on this? I am using Shiny 0.13.2 with R 3.3.1 and httupv 1.3.3 to run a web app and I keep getting the following message and corresponding abort quite frequently:

>  runApp(host = "0.0.0.0", port = 8080)

Listening on http://0.0.0.0:8080
Error writing response: -1
R: src/unix/core.c:84: uv_close: Assertion `!(handle->flags & (UV_CLOSING | UV_CLOSED))' failed.
Aborted (core dumped)

I will try @actsasflinn tree and see if libuv 1.4 solves the issue.

[jcheng5]

You can also try my libuv-1.8.0 branch.

Can you tell me if this problem happens when you do shiny::runExample("01_hello")? Or only with your own app?

[hcorrada]

@jcheng5 are you planning on moving to libuv-1.8.0 branch? Should I plan to port daemonization code accordingly?

[jcheng5]

Not imminently--I don't have the cycles right now. I believe there was some issue with getting that branch to build on some versions of Red Hat.

[hcorrada]

Ok, thanks (out of sight out of mind). Let me know if I should give up on windows daemonization pull request too :-)

[elferdo]

@jcheng5 The uv_close error seems to be gone with libuv 1.4.0, that's good news. Locally my shiny app works perfect with httpuv from CRAN, the error began showing up when the app went live, which makes me think it has to do with concurrency, but I haven't traced it down nor found a way to reproduce it.