libuv about cl-async HOT 11 CLOSED

Nope. Doesn't wrap well at all in CFFI. Believe me, I tried.

from cl-async.

Libuv author here. What kind of issues were you running into? Hop into #libuv on freenode.org and I'll be happy to guide you along.

Libuv might be a good fit for your project. Some of the open issues (esp. the Windows ones) Just Work(TM) in libuv.

from cl-async.

@bnoordhuis, I had no issue with libuv itself, in fact it was my first choice after much research. The problem stems from the fact that some of the function calls were returning structures instead of pointers to structures. CFFI, the lisp <--> C bridge, does not deal well with values on the stack. It can be faked when passing a struct into a function by deconstructing the struct into its arguments and passing those in individually in the correct order, but trying to read values from a struct returned on the stack from a function call usually results in a memory read error/segfault because CFFI expects pointers or single values.

From what I remember when I was wrapping libuv, there were a few functions returning struct values (address functions if I remember correctly, but it's been months so I don't remember). I did try my best to destructure the struct values and pass those them directly into the function(s) accepting them, but it just didn't work and after a few hours of tweaking and trying so I gave up and searched for alternatives.

That said, one can write a wrapper for the functions that return structs, but like I mention in the docs I want at most one c dependency.

So really, it's not libuv, it's more the fact that libuv uses a techinique in a handful of crucial places that lisp just doesn't deal well with. Working around it proved difficult and prompted me to search for alternatives.

That said, I might try again soon. I've been toying with the idea of allowing different backends (libuv, libevent, IOLib) and if I can successfully get a few tests running in libuv, I'd be glad to start work on this (issue #62). There are some bugs I would like to fix in the meantime in cl-async, but once that's taken care of, I'll gladly take another shot. If I have any problems while wrapping libuv, I'll gladly stop by #libuv and ask for help!

from cl-async.

From what I remember when I was wrapping libuv, there were a few functions returning struct values (address functions if I remember correctly, but it's been months so I don't remember).

Right, other bindings authors have complained about that as well. I'm okay with changing that.

from cl-async.

One thing I've seen a few other libraries do is export a set of FFI functions that basically wrap any function that takes/returns a struct by value and it allows it to take/return that same struct by ref. Then you don't have to change your API.

from cl-async.

It's no great hassle to change it (except for updating all the tests) and it'll let us fold some API functions, e.g. uv_tcp_bind and uv_tcp_bind6. It's something we (my co-author and me) have discussed before.

I've opened an issue in case you want to track it: joyent/libuv#684

from cl-async.

joyent/libuv#684

Libuv finally got ref-based (vs value-based) passing done. I think it's time to try and give cl-libuv a shot, and potentially integrate with cl-async.

from cl-async.

Any progress here?
Is cl-libuv usable with cl-async now?

from cl-async.

No, but libevent is giving cl-async enough strange bugs that I could be forced to do the upgrade soon enough.

Stay tuned here. I have a number of projects going on right now so it's a bit of juggling to get this done.

from cl-async.

http://orthecreedence.github.io/cl-async/2014/11/29/cl-async-now-using-libuv.html

Done =]

from cl-async.

Amazing!

On Tue, 09 Dec 2014 00:39:08 -0800,
andrew lyon [email protected] wrote:

http://orthecreedence.github.io/cl-async/2014/11/29/cl-async-now-using-libuv.html

Done =]

---

Reply to this email directly or view it on GitHub:
#32 (comment)

from cl-async.