Lua co-routines

[Jim Jagielski <ji...@jaguNET.com>]

I've been keen on libmill, which provides a golang-like
goroutine library. It seems that such functionality would
be cool for APR and APR-based apps (like serf and httpd).

Then I started thinking: Lua also has a great coroutine impl
and it is also MIT licensed and might be easier to fold
into APR. Anyone ever look at that? Having something like
apr_routine() would be awful cool.

Re: Lua co-routines

[Jim Jagielski <ji...@jaguNET.com>]

> On Sep 26, 2015, at 3:11 PM, Branko Čibej <br...@apache.org> wrote:
> 
> On 26.09.2015 19:10, Jim Jagielski wrote:
>> I've been keen on libmill, which provides a golang-like
>> goroutine library. It seems that such functionality would
>> be cool for APR and APR-based apps (like serf and httpd).
>> 
>> Then I started thinking: Lua also has a great coroutine impl
>> and it is also MIT licensed and might be easier to fold
>> into APR. Anyone ever look at that? Having something like
>> apr_routine() would be awful cool.
> 
> Whilst I agree that co-routines are useful, I don't see a good reason to
> fold this into APR. I feel that APR has already departed far from its
> "portable runtime" promise. With database connectors and whatnot it's
> become a bit of a mastodont. We really should rethink what we're doing
> here; APR is no longer the "Apache (httpd) Portable Runtime", it's used
> by other projects that don't need all the luggage.
> 
> And furthermore, it's not 1999 any more: the reasons why it was a good
> idea to bundle, e.g., an XML parser or a BerkeleyDB frontend into APR
> are no longer valid. I wish we'd pared APR-2.0 down to the basics of
> memory management, filsystem and I/O abstraction. We surely don't want
> to invent yet another coprocessing library.
> 

Well, for APR2, I wouldn't mind looking into using pocore's
memory and hash/tables as our base. 

Re: Lua co-routines

[Graham Leggett <mi...@sharp.fm>]

On 26 Sep 2015, at 9:11 PM, Branko Čibej <br...@apache.org> wrote:

> Whilst I agree that co-routines are useful, I don't see a good reason to
> fold this into APR. I feel that APR has already departed far from its
> "portable runtime" promise. With database connectors and whatnot it's
> become a bit of a mastodont. We really should rethink what we're doing
> here; APR is no longer the "Apache (httpd) Portable Runtime", it's used
> by other projects that don't need all the luggage.

Yep, APR v1 got it right, with the portable runtime in APR, and “bigger stuff that integrates with APR (usually APR pools)” in apr-util.

Now we have one big monolithic APR v2, and it isn’t ideal.

> And furthermore, it's not 1999 any more: the reasons why it was a good
> idea to bundle, e.g., an XML parser or a BerkeleyDB frontend into APR
> are no longer valid. I wish we'd pared APR-2.0 down to the basics of
> memory management, filsystem and I/O abstraction. We surely don't want
> to invent yet another coprocessing library.

The main reasons you’d want to do this are to integrate cleanly with APR pools. I just had to use POSIX message queues and ended building an “APR like” abstraction for them so they would integrate nicely, it is a good thing these things exist.

Regards,
Graham
—

Re: Lua co-routines

[Branko Čibej <br...@apache.org>]

On 26.09.2015 19:10, Jim Jagielski wrote:
> I've been keen on libmill, which provides a golang-like
> goroutine library. It seems that such functionality would
> be cool for APR and APR-based apps (like serf and httpd).
>
> Then I started thinking: Lua also has a great coroutine impl
> and it is also MIT licensed and might be easier to fold
> into APR. Anyone ever look at that? Having something like
> apr_routine() would be awful cool.

Whilst I agree that co-routines are useful, I don't see a good reason to
fold this into APR. I feel that APR has already departed far from its
"portable runtime" promise. With database connectors and whatnot it's
become a bit of a mastodont. We really should rethink what we're doing
here; APR is no longer the "Apache (httpd) Portable Runtime", it's used
by other projects that don't need all the luggage.

And furthermore, it's not 1999 any more: the reasons why it was a good
idea to bundle, e.g., an XML parser or a BerkeleyDB frontend into APR
are no longer valid. I wish we'd pared APR-2.0 down to the basics of
memory management, filsystem and I/O abstraction. We surely don't want
to invent yet another coprocessing library.

-- Brane