Skip to content
This repository

libuv #32

Open
h3x3d opened this Issue · 7 comments

3 participants

h3x3d andrew lyon Ben Noordhuis
h3x3d

Don't you plan migrating to https://github.com/joyent/libuv ?

andrew lyon

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

Ben Noordhuis

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.

andrew lyon

@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!

Ben Noordhuis

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.

andrew lyon

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.

Ben Noordhuis

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

andrew lyon

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.

andrew lyon orthecreedence referenced this issue
Closed

libev #88

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.