aantron
commented
7 years ago The status of this is:
- We'd like to make the C code more maintainable. It's really rough right now. Using
Lwt_preemptive(perhaps improved) with cstruct is definitely a good way to do that. - I believe this is more or less how Async does most (or all?) of its blocking system calls, e.g. this link is from the
getcwdissue. - I believe the reason for why there is a whole bunch of C code in Lwt, is because when not compiling with
-threads,Thread,Mutex, etc. are not available. So, a threading module got implemented in C. I haven't looked in the configuration to know deeply enough, but: is there a platform on which Lwt could be configured to compile all that threaded C code, that doesn't have OCaml threads? If so, is that platform important? I didn't look, but does the C code compile to blocking code if threads are not available in C? - There is also the minor issue of the global interpreter lock, which would be taken by calling back into OCaml right before doing a system call. I doubt this is important, however. It also shouldn't be an issue once the multicore runtime is available.
- The biggest thing constraining this right now is the potential port to libuv (#328), which would replace Lwt's C code by uwt/libuv, rather than by
Lwt_preemptive+cstruct. I think this is a more promising direction, as we could also provide an isomorphic Node.js binding (#270) for use with js_of_ocaml and BuckleScript, and expect to get (almost?) the same semantics (since Node.js is calling libuv internally). Together with a port of the core to ES6 promises, Lwt could provide a common I/O library for porting code and skill sets beween Node and native, and the core between Node, native, and front-end. It would also unite the various ecosystems to some degree. This could be a major win for convincing people to adopt OCaml and Reason :) - Interestingly, libuv doesn't have a non-blocking wrapper around
getcwd, but uwt does, so we may still want to use cstruct for a portion of the API, even if we go down the uwt/libuv path.
avsm
Currently, providing new system calls involve several files with many macros.
Is this the kind of thing that cstruct could make simpler? And if so How many dependencies cstruct has? Which ones? Is it worth rewriting the unix bindings with a cstruct version?
I'll investigate some of that. If someone already have answers to those questions, please comment below.