Grant Proposal: Implement Perl Binding for libuv
Mon, 11-Nov-2019 by
Coke
edit post
<, wrapping as many of
the features and types as is practical and useful for Perl 5.
## Benefits to the Perl Community
The `libuv` library provides a multi-platform event system, and is the basis
for the `nodejs` JavaScript and `moarvm` Perl 6 runtimes and the `neovim`
text editor, to give a few examples. It is widely used as a support library by
a wide variety of software and has language bindings for C#, Python 3, C++ and
Lua, as well as being accessible directly via NodeJS. Adding Perl 5 to this
list will allow programmers familiar with it from other langauges to make use
of it from Perl 5, and will bring to Perl 5 several useful abilities the
library provides that most other event systems do not.
## Deliverables
The primary deliverable would be a newer version of [UV](https://metacpan.org/pod/UV) whose internal
implementation has been reworked to have a better architecture to more easily
maintain going forward and that eliminates the current leaks and hangs on
polling.
A number of known bugs already exist and a few are collected on GitHub (at
[https://github.com/genio/p5-UV/issues](https://github.com/genio/p5-UV/issues)). Other issues are collected on the
[Mojo::Reactor::UV](https://metacpan.org/pod/Mojo::Reactor::UV) module, which could be considered to be a real-world
example usage: [https://github.com/Grinnz/Mojo-Reactor-UV/issues](https://github.com/Grinnz/Mojo-Reactor-UV/issues).
In addition to that first release, subsequent releases would be made to add
the missing features of the current implementation, namely requests:
[http://docs.libuv.org/en/v1.x/request.html](http://docs.libuv.org/en/v1.x/request.html). The currently missing handle
objects would also be added.
Upon fully implementing the features of the library, a secondary deliverable
will be a set of blog posts and presentations to educate potential users,
and to demonstrate its use. Some blog posts may draw contrasts and
similarities to other languages, helping to further emphasize the impact of
this cross-platform library in all of these languages. In particular,
parallels to Perl 6, Python 3, and NodeJS may be useful as those languages
are ones that potential users may also be familiar with.
## Project Details
While a binding already exists in the namespace [UV](https://metacpan.org/pod/UV), it suffers many
shortcomings and bugs. The current maintainer is willing to work with me on
rebuilding it in a better form, now that the existing structure is more
understood. We should be able to preserve much of the existing documentation
and unit tests, which will be helpful in getting a good start.
## Inch-stones
The heart of [UV](https://metacpan.org/pod/UV), [UV::Loop](https://metacpan.org/pod/UV::Loop) has been implemented, but is in need of a
rewrite to fix it and clear up the bugs.
Once this is done, the various handle types need to be wrapped; around 15
different types in total. Writing a good implementation for any one of them is
likely to take an amount of time and research, but from that point the
remaining ones should follow along somewhat easier, as they all follow a
similar pattern.
## Project Schedule
There are two main phases to this project.
The first phase will involve rebuilding the XS implementation of the current
portion of `libuv` which has already been attempted, sufficient to cover the
existing unit tests for the loop itself and the currently-implemented handle
types (`check`, `handle`, `idle`, `poll`, `prepare` and `timer`). As
mentioned, it is likely that the existing documentation and unit tests of
these can be retained and provided with a better code implementation. The
tests will help illustrate that the implementation has been completed.
This first phase should take around 50 to 60 hours of work.
The second phase can then proceed to implement the remaining handle types that
are not currently provided. Each of these will be fairly independent and
incremental in nature. each one completed will provide more utility
independently of the others, so if one of them turns out to be too complicated
to provide, no work is rendered useless having completed the others.
While there are more types to this phase, each should be a similar pattern to
the others, so this should take no more than around 40 hours to finish.
This makes a total of 100 hours.
## Completeness Criteria
At time of writing there are no known CPAN modules able to use [UV](https://metacpan.org/pod/UV) because
it is too unstable at present for even the smallest of use cases. A useful
moment to consider as a completion target may be when the module is
sufficiently robust that it can be used as a dependency by at least a few
other CPAN modules that currently use [EV](https://metacpan.org/pod/EV).
For example, [Mojo::Reactor::UV](https://metacpan.org/pod/Mojo::Reactor::UV) and [IO::Async::Loop](https://metacpan.org/pod/IO::Async::Loop) could greatly benefit
using this new library.
CPAN shows a great number of other modules using [EV](https://metacpan.org/pod/EV) by many authors, and
any of these could also be used as test-cases for the robustness of [UV](https://metacpan.org/pod/UV):
[https://metacpan.org/requires/distribution/EV?sort=\[\[2,1\]\]](https://metacpan.org/requires/distribution/EV?sort=[[2,1]])
## Bio
I am Paul Evans, PEVANS on CPAN ([https://metacpan.org/author/PEVANS](https://metacpan.org/author/PEVANS)).
I have been a CPAN maintainer for over 10 years, and currently have 155
distributions under my name. Among this set of modules are a number of
dual-life core modules - [List::Util](https://metacpan.org/pod/List::Util) and [IO::Socket::IP](https://metacpan.org/pod/IO::Socket::IP) being two that
may be among the most heavily-depended upon on CPAN. I have a number of
XS-based modules, including some such as [Syntax::Keyword::Try](https://metacpan.org/pod/Syntax::Keyword::Try) and
[Future::AsyncAwait](https://metacpan.org/pod/Future::AsyncAwait) that provide keyword plugins to extend the Perl syntax.
I am familiar with many parts of the core perl interpreter, and am well-known
to many of the perl5-porters group.
I maintain a blog on a variety of programming topics, often posting on
Perl-related matters. [http://leonerds-code.blogspot.com/search/label/perl](http://leonerds-code.blogspot.com/search/label/perl).
I have spoken at most London Perl Workshops in the past few years, and attend
(and sometimes talk at) the European occurance of what was formerly called
YAPC::EU, most recently called TPCiG. I maintain a YouTube playlist of
recordings of talks I have given.
[https://www.youtube.com/playlist?list=PL9-uV\_AVx5FOzWJIvpuebmyiIuNd4L7GJ](https://www.youtube.com/playlist?list=PL9-uV_AVx5FOzWJIvpuebmyiIuNd4L7GJ)
I have successfully completed a TFP project before, to improve the
implementation of the [Future::AsyncAwait](https://metacpan.org/pod/Future::AsyncAwait) module.
]]>
Comments (1)
I highly recommend this grant be accepted. I also hope that both the author, the grants committee, and p5p will keep a long-view for this module to be included with the Perl core some time in the future as a view towards unifying the disparate IO loops on CPAN (which can still exist as front-ends to a unified compiled backend provided by the language). IO loops have become indispensable features of modern programming, libuv being the primary example as Paul mentions, and Perl will benefit from having this module, in core if possible.
