Lua coroutines to async/await feature

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Lua coroutines to async/await feature

Dibyendu Majumdar
Hi

This is just something I have been wondering about. I personally have
not yet found a use case for Lua's coroutines - the main reason being
that the resume has to be explicit. What would be more useful is if
the coroutine semantics could be harnessed to create an async/await
type solution as in C#. That is, can a solution be found to
automatically resume the coroutine when an event associated with a
'yield' completes. As Lua is single threaded so the solution needs to
resume the coroutine within the same OS thread.

I haven't really tried solving this but I thought it might be a useful
enhancement to Lua if a solution could be found. I imagine that a
background OS thread will be needed to monitor completion of events
and then some coordination with the VM will be necessary to resume
suspended coroutines, maybe whenever the VM does an operation that
requires system resources. In some ways the 'go' language works like
this - i.e. there is a background scheduler that swaps in suspended
goroutines to the thread whenever execution would otherwise pause.

This is just me thinking aloud, so please feel free to shoot it down,
or point me to existing solutions that achieve this (I imagine
projects that integrate libuv might be doing this already).

Thanks and Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Lua coroutines to async/await feature

Russell Haley
On Tue, Nov 22, 2016 at 4:59 PM, Dibyendu Majumdar
<[hidden email]> wrote:

> Hi
>
> This is just something I have been wondering about. I personally have
> not yet found a use case for Lua's coroutines - the main reason being
> that the resume has to be explicit. What would be more useful is if
> the coroutine semantics could be harnessed to create an async/await
> type solution as in C#. That is, can a solution be found to
> automatically resume the coroutine when an event associated with a
> 'yield' completes. As Lua is single threaded so the solution needs to
> resume the coroutine within the same OS thread.
>
> I haven't really tried solving this but I thought it might be a useful
> enhancement to Lua if a solution could be found. I imagine that a
> background OS thread will be needed to monitor completion of events
> and then some coordination with the VM will be necessary to resume
> suspended coroutines, maybe whenever the VM does an operation that
> requires system resources.

Something like this?
http://25thandclement.com/~william/projects/cqueues.html

Very slick stuff. Also see

https://github.com/daurnimator/lua-http

and my shameless plug:

https://github.com/RussellHaley/lua-http-endpoints


Russ

> In some ways the 'go' language works like
> this - i.e. there is a background scheduler that swaps in suspended
> goroutines to the thread whenever execution would otherwise pause.
>
> This is just me thinking aloud, so please feel free to shoot it down,
> or point me to existing solutions that achieve this (I imagine
> projects that integrate libuv might be doing this already).
>
> Thanks and Regards
> Dibyendu
>

Reply | Threaded
Open this post in threaded view
|

Re: Lua coroutines to async/await feature

Russell Haley
On Tue, Nov 22, 2016 at 6:12 PM, Russell Haley <[hidden email]> wrote:

> On Tue, Nov 22, 2016 at 4:59 PM, Dibyendu Majumdar
> <[hidden email]> wrote:
>> Hi
>>
>> This is just something I have been wondering about. I personally have
>> not yet found a use case for Lua's coroutines - the main reason being
>> that the resume has to be explicit. What would be more useful is if
>> the coroutine semantics could be harnessed to create an async/await
>> type solution as in C#. That is, can a solution be found to
>> automatically resume the coroutine when an event associated with a
>> 'yield' completes. As Lua is single threaded so the solution needs to
>> resume the coroutine within the same OS thread.
>>
>> I haven't really tried solving this but I thought it might be a useful
>> enhancement to Lua if a solution could be found. I imagine that a
>> background OS thread will be needed to monitor completion of events
>> and then some coordination with the VM will be necessary to resume
>> suspended coroutines, maybe whenever the VM does an operation that
>> requires system resources.
>
> Something like this?
> http://25thandclement.com/~william/projects/cqueues.html
>
> Very slick stuff. Also see
>
> https://github.com/daurnimator/lua-http
>
> and my shameless plug:
>
> https://github.com/RussellHaley/lua-http-endpoints
>
Sorry, missed a good link. https://github.com/wahern/cqueues/wiki
Daurnimators got some really nice cqueue enabled libraries I'm looking
forward to using (See the "Libraries that use cqueues" page).

> Russ
>
>> In some ways the 'go' language works like
>> this - i.e. there is a background scheduler that swaps in suspended
>> goroutines to the thread whenever execution would otherwise pause.
>>
>> This is just me thinking aloud, so please feel free to shoot it down,
>> or point me to existing solutions that achieve this (I imagine
>> projects that integrate libuv might be doing this already).
>>
>> Thanks and Regards
>> Dibyendu
>>

Reply | Threaded
Open this post in threaded view
|

Re: Lua coroutines to async/await feature

William Ahern
In reply to this post by Dibyendu Majumdar
On Wed, Nov 23, 2016 at 12:59:30AM +0000, Dibyendu Majumdar wrote:

> Hi
>
> This is just something I have been wondering about. I personally have
> not yet found a use case for Lua's coroutines - the main reason being
> that the resume has to be explicit. What would be more useful is if
> the coroutine semantics could be harnessed to create an async/await
> type solution as in C#. That is, can a solution be found to
> automatically resume the coroutine when an event associated with a
> 'yield' completes. As Lua is single threaded so the solution needs to
> resume the coroutine within the same OS thread.

For some definition of "automatic", this is actually quite trivial.
Obviously it cannot be too automatic because Lua has a contract with C code.
But this can be implemented quite transparently from the perspective of
Lua-script space. The biggest caveat is that Lua objects are multithread
safe.

> I haven't really tried solving this but I thought it might be a useful
> enhancement to Lua if a solution could be found. I imagine that a
> background OS thread will be needed to monitor completion of events
> and then some coordination with the VM will be necessary to resume
> suspended coroutines, maybe whenever the VM does an operation that
> requires system resources. In some ways the 'go' language works like
> this - i.e. there is a background scheduler that swaps in suspended
> goroutines to the thread whenever execution would otherwise pause.

Goroutines work more like Lua coroutines than you'd think. While the kernel
threads that goroutines execute on are preemptively scheduled, AFAIU the Go
goroutine scheduler is cooperative. Control is usually passed between
goroutines when doing reads and writs to a channel. The Go compiler also
inserts checkpoints in compiled code, usually at function call points, to
support garbage collection. Scheduling might also occur at those points.

So while goroutines _feel_ preemptively scheduled, they're actually
cooperative scheduled underneath the hood. It's why loops in Go code that
don't do any I/O, polling, or message passing can hog the entire kernel
thread and stop progress of other goroutines as well as the garbage
collector.

Lua's coroutines can be used in much the same way, you just need to
implement a scheduler much like Go does. Lua gives you the tools to
implement those patterns, you just need to build an application framework
around to make it feel transparent.

I might be mistaken, but C# I suspect async/await is implemented much the
way. Because C# doesn't support coroutines, you have to annotate routines
with async. In the vocabulary of Lua, calling a function marked as async in
C# is like calling a function using coroutine.wrap in Lua. In both cases the
stack frame of the invocation is put onto a separate stack independent from
the caller. In both cases, when the routine "yields" a value, it's state is
kept on the stack. The only real difference is that

1) Lua doesn't support sharing objects between kernel threads, so you can't
yield a value that will be used in another kernel thread; and

2) Lua code can yield from recursively invoked functions, whether or not the
routine was annotated. Whereas in C# (and Python and JavaScript) you can
only yield from an annotated function. Lua's coroutines are actually more
powerful and flexible. The thread-safety limitation follows from the
implemenentation of the VM, not from coroutines generally. C# doesn't
support real coroutines likely because, much like many other virtual
machines, it implements recursion internally on top of the so-called
"C stack", whereas in Lua the VM stack is independent from the C stack.
Because of legacy ABI requirements, the C stack must be very large, so it
would be inefficient to allocate a new C stack for every invocation of an
async routine. A Lua coroutine, by contrast, uses dynamic memory for the
VM's stack and it can be just as efficient or more efficient than the data
structure C# has to allocate for async invocations, especially when you have
chains of async invocations.

Goroutines don't need to support the platform's native ABI issues. Compiled
Go code can initialize a new goroutines with a tiny stack that can grow
dynamically just like Lua. When calling out into C code, Go will invoke the
routine directly on the kernel thread's C stack, and copy the result back
onto the stack of the goroutine. That's why calling C code from Go is slow
and problematic in highly concurrent Go code. If 10,000 goroutines all
invoked a C function, the Go schedule would be forced to create 10,000
kernel threads (each with a multi-megabyte stack), or serialize access to a
smaller number of dedicated kernel threads.

> This is just me thinking aloud, so please feel free to shoot it down,
> or point me to existing solutions that achieve this (I imagine
> projects that integrate libuv might be doing this already).
>
> Thanks and Regards
> Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Lua coroutines to async/await feature

Xavier Wang
In reply to this post by Dibyendu Majumdar

Dibyendu Majumdar <[hidden email]>于2016年11月23日 周三上午8:59写道:
Hi

This is just something I have been wondering about. I personally have
not yet found a use case for Lua's coroutines - the main reason being
that the resume has to be explicit. What would be more useful is if
the coroutine semantics could be harnessed to create an async/await
type solution as in C#. That is, can a solution be found to
automatically resume the coroutine when an event associated with a
'yield' completes. As Lua is single threaded so the solution needs to
resume the coroutine within the same OS thread.

I haven't really tried solving this but I thought it might be a useful
enhancement to Lua if a solution could be found. I imagine that a
background OS thread will be needed to monitor completion of events
and then some coordination with the VM will be necessary to resume
suspended coroutines, maybe whenever the VM does an operation that
requires system resources. In some ways the 'go' language works like
this - i.e. there is a background scheduler that swaps in suspended
goroutines to the thread whenever execution would otherwise pause.

This is just me thinking aloud, so please feel free to shoot it down,
or point me to existing solutions that achieve this (I imagine
projects that integrate libuv might be doing this already).

Thanks and Regards
Dibyendu

Or my toy coroutine scheduler project: ​​https://github.com/starwing/luasched
Reply | Threaded
Open this post in threaded view
|

Re: Lua coroutines to async/await feature

Eike Decker
In reply to this post by Dibyendu Majumdar

2016-11-23 1:59 GMT+01:00 Dibyendu Majumdar <[hidden email]>:
Hi

This is just something I have been wondering about. I personally have
not yet found a use case for Lua's coroutines - the main reason being
that the resume has to be explicit. What would be more useful is if
the coroutine semantics could be harnessed to create an async/await
type solution as in C#. That is, can a solution be found to
automatically resume the coroutine when an event associated with a
'yield' completes. As Lua is single threaded so the solution needs to
resume the coroutine within the same OS thread.

I haven't really tried solving this but I thought it might be a useful
enhancement to Lua if a solution could be found. I imagine that a
background OS thread will be needed to monitor completion of events
and then some coordination with the VM will be necessary to resume
suspended coroutines, maybe whenever the VM does an operation that
requires system resources. In some ways the 'go' language works like
this - i.e. there is a background scheduler that swaps in suspended
goroutines to the thread whenever execution would otherwise pause.

This is just me thinking aloud, so please feel free to shoot it down,
or point me to existing solutions that achieve this (I imagine
projects that integrate libuv might be doing this already).

Thanks and Regards
Dibyendu

Non blocking single threaded network socket library with this property: http://keplerproject.github.io/copas/ 

Cheers,
Eike
Reply | Threaded
Open this post in threaded view
|

Re: Lua coroutines to async/await feature

Dibyendu Majumdar
In reply to this post by William Ahern
On 23 November 2016 at 02:38, William Ahern <[hidden email]> wrote:

> On Wed, Nov 23, 2016 at 12:59:30AM +0000, Dibyendu Majumdar wrote:
>> This is just something I have been wondering about. I personally have
>> not yet found a use case for Lua's coroutines - the main reason being
>> that the resume has to be explicit. What would be more useful is if
>> the coroutine semantics could be harnessed to create an async/await
>> type solution as in C#. That is, can a solution be found to
>> automatically resume the coroutine when an event associated with a
>> 'yield' completes. As Lua is single threaded so the solution needs to
>> resume the coroutine within the same OS thread.
>
> For some definition of "automatic", this is actually quite trivial.
> Obviously it cannot be too automatic because Lua has a contract with C code.
> But this can be implemented quite transparently from the perspective of
> Lua-script space. The biggest caveat is that Lua objects are multithread
> safe.
>

Thanks for the detailed reply - much appreciated. Did you mean above
that Lua objects are not multi-thread safe?

>> I haven't really tried solving this but I thought it might be a useful
>> enhancement to Lua if a solution could be found. I imagine that a
>> background OS thread will be needed to monitor completion of events
>> and then some coordination with the VM will be necessary to resume
>> suspended coroutines, maybe whenever the VM does an operation that
>> requires system resources. In some ways the 'go' language works like
>> this - i.e. there is a background scheduler that swaps in suspended
>> goroutines to the thread whenever execution would otherwise pause.
>
> Goroutines work more like Lua coroutines than you'd think. While the kernel
> threads that goroutines execute on are preemptively scheduled, AFAIU the Go
> goroutine scheduler is cooperative. Control is usually passed between
> goroutines when doing reads and writs to a channel. The Go compiler also
> inserts checkpoints in compiled code, usually at function call points, to
> support garbage collection. Scheduling might also occur at those points.
>
> So while goroutines _feel_ preemptively scheduled, they're actually
> cooperative scheduled underneath the hood. It's why loops in Go code that
> don't do any I/O, polling, or message passing can hog the entire kernel
> thread and stop progress of other goroutines as well as the garbage
> collector.
>
> Lua's coroutines can be used in much the same way, you just need to
> implement a scheduler much like Go does. Lua gives you the tools to
> implement those patterns, you just need to build an application framework
> around to make it feel transparent.
>

I had a quick look at your project cqueues that presumably does this.
Would it be a good idea to port this to libuv so that Windows can be
supported as well (I understand cqueues only works on UNIX like
environments)?

Regards
Dibyendu

Reply | Threaded
Open this post in threaded view
|

Re: Lua coroutines to async/await feature

Dibyendu Majumdar
In reply to this post by Russell Haley
On 23 November 2016 at 02:16, Russell Haley <[hidden email]> wrote:

>> On Tue, Nov 22, 2016 at 4:59 PM, Dibyendu Majumdar
>>> This is just something I have been wondering about. I personally have
>>> not yet found a use case for Lua's coroutines - the main reason being
>>> that the resume has to be explicit. What would be more useful is if
>>> the coroutine semantics could be harnessed to create an async/await
>>> type solution as in C#. That is, can a solution be found to
>>> automatically resume the coroutine when an event associated with a
>>> 'yield' completes. As Lua is single threaded so the solution needs to
>>> resume the coroutine within the same OS thread.
>>>
>> Something like this?
>> http://25thandclement.com/~william/projects/cqueues.html
>>
>> Very slick stuff. Also see
>>
>> https://github.com/daurnimator/lua-http
>>
>> and my shameless plug:
>>
>> https://github.com/RussellHaley/lua-http-endpoints
>>
> Sorry, missed a good link. https://github.com/wahern/cqueues/wiki
> Daurnimators got some really nice cqueue enabled libraries I'm looking
> forward to using (See the "Libraries that use cqueues" page).
>

Thank you!

Reply | Threaded
Open this post in threaded view
|

Re: Lua coroutines to async/await feature

Russell Haley
In reply to this post by Dibyendu Majumdar
On Wed, Nov 23, 2016 at 11:11 AM, Dibyendu Majumdar
<[hidden email]> wrote:

> On 23 November 2016 at 02:38, William Ahern <[hidden email]> wrote:
>> On Wed, Nov 23, 2016 at 12:59:30AM +0000, Dibyendu Majumdar wrote:
>>> This is just something I have been wondering about. I personally have
>>> not yet found a use case for Lua's coroutines - the main reason being
>>> that the resume has to be explicit. What would be more useful is if
>>> the coroutine semantics could be harnessed to create an async/await
>>> type solution as in C#. That is, can a solution be found to
>>> automatically resume the coroutine when an event associated with a
>>> 'yield' completes. As Lua is single threaded so the solution needs to
>>> resume the coroutine within the same OS thread.
>>
>> For some definition of "automatic", this is actually quite trivial.
>> Obviously it cannot be too automatic because Lua has a contract with C code.
>> But this can be implemented quite transparently from the perspective of
>> Lua-script space. The biggest caveat is that Lua objects are multithread
>> safe.
>>
>
> Thanks for the detailed reply - much appreciated. Did you mean above
> that Lua objects are not multi-thread safe?
>
>>> I haven't really tried solving this but I thought it might be a useful
>>> enhancement to Lua if a solution could be found. I imagine that a
>>> background OS thread will be needed to monitor completion of events
>>> and then some coordination with the VM will be necessary to resume
>>> suspended coroutines, maybe whenever the VM does an operation that
>>> requires system resources. In some ways the 'go' language works like
>>> this - i.e. there is a background scheduler that swaps in suspended
>>> goroutines to the thread whenever execution would otherwise pause.
>>
>> Goroutines work more like Lua coroutines than you'd think. While the kernel
>> threads that goroutines execute on are preemptively scheduled, AFAIU the Go
>> goroutine scheduler is cooperative. Control is usually passed between
>> goroutines when doing reads and writs to a channel. The Go compiler also
>> inserts checkpoints in compiled code, usually at function call points, to
>> support garbage collection. Scheduling might also occur at those points.
>>
>> So while goroutines _feel_ preemptively scheduled, they're actually
>> cooperative scheduled underneath the hood. It's why loops in Go code that
>> don't do any I/O, polling, or message passing can hog the entire kernel
>> thread and stop progress of other goroutines as well as the garbage
>> collector.
>>
>> Lua's coroutines can be used in much the same way, you just need to
>> implement a scheduler much like Go does. Lua gives you the tools to
>> implement those patterns, you just need to build an application framework
>> around to make it feel transparent.
>>
>
> I had a quick look at your project cqueues that presumably does this.
> Would it be a good idea to port this to libuv so that Windows can be
> supported as well (I understand cqueues only works on UNIX like
> environments)?

libuv is a different beast that does the same thing but not
specifically to lua, it was written for the node.js project if I
remember correctly (https://en.wikipedia.org/wiki/Libuv). Mr. Aherns
solution is very elegant because it blends yielding and direct
connection to the os calls. I would love to hear more from Mr. Ahern
about this!

Have you looked at luvit (https://luvit.io/install.html)?

Russ

Reply | Threaded
Open this post in threaded view
|

Re: Lua coroutines to async/await feature

William Ahern
In reply to this post by Dibyendu Majumdar
On Wed, Nov 23, 2016 at 07:11:51PM +0000, Dibyendu Majumdar wrote:
> On 23 November 2016 at 02:38, William Ahern <[hidden email]> wrote:
<snip>
> > Lua-script space. The biggest caveat is that Lua objects are multithread
> > safe.
> >
>
> Thanks for the detailed reply - much appreciated. Did you mean above
> that Lua objects are not multi-thread safe?

Oops. Yes, I meant not multi-thread safe.

<snip>
> I had a quick look at your project cqueues that presumably does this.
> Would it be a good idea to port this to libuv so that Windows can be
> supported as well (I understand cqueues only works on UNIX like
> environments)?

This is sort of difficult to explain, but in short porting to cqueues is a
little non-sensical.

cqueues is designed not to use callbacks internally or to require callbacks.
That way it can be more easily embedded into projects (applications,
libraries). cqueues is based around the notion of restartable operations. If
you've every had to link an async DNS library to an async socket library to
to an async database library, all utilizing callbacks, you very quickly
realize how horrible callbacks are as a generic interface. They don't
compose well because they cannot make use of the most fundamental control
flow model in almost every language--synchronous function call and return,
where the function result is returned directly.

By contrast, a restartable interface makes it much easier to combine
different libraries because you utilize the normal control flow patterns. It
works just like combining any other code--by invoking a function and
operating on the return value. The only difference is that the return value
might be "try again".

Were cqueues ported to Windows (and that's on the TODO), it would be easy to
tie cqueues into libuv's event loop, just like it's easy to tie cqueues into
libevent or any other common event loop. But only in so far as you're using
libuv for readiness polling; it's I/O interfaces don't make sense in the
cqueues model, and in any event would be superfluous. If you're already
using libuv you don't really need the core cqueues event scheduler, anyhow,
nor the supplemental socket and DNS library.

Porting cqueues to Windows involves serious refactoring of cqueues. epoll,
kqueue, and Solaris Ports all utilize a special descriptor as a handle to
the kernel's polling state. This descriptor can be polled like any other
descriptor. When it polls ready it means events can be dequeued. That's why
cqueues is easy to embed into other event loops--the descriptor is a
transparent proxy for all the events managed by cqueues internally. Even if
cqueues is managing 100,000 socket events, you only need to poll that one
descriptor in your application's mainloop to know to resume the cqueues
controller. There are no parallel threads or callbacks involved; you don't
need to inform cqueues which event is ready; you don't need to worry about
re-entrancy issues (i.e. will cqueues callback into your event loop again);
etc.

Microsoft's vision for highly concurrent asynchronous tasks on Windows has
always been based on a multi-threaded, callback model. Even overlapped I/O
uses multiple threads within the kernel. Some interfaces, like
WaitForMultipleObjects, are superficially similar to epoll, but they're
really just a queue for the results of callbacks invoked from other threads.
And they weren't meant to scale in the single-threaded case the same way
epoll, kqueue, etc can. So it's quite a chore to match up the cqueues model
in a Windows environment. Libraries like libuv and libevent's buffer
interface actually solve this by forcing a more Windows-like model on Unix
applications. For basic tasks this is simple and convenient; but
composability suffers and building complex applications many moving parts
results in so-called callback hell as you bind various callback interfaces
together while struggling to maintain memory and thread safety.


Reply | Threaded
Open this post in threaded view
|

Async libraries and IOCP [from] Lua coroutines to async/await feature

Andrew Starks-2
In reply to this post by Dibyendu Majumdar

On Wed, Nov 23, 2016 at 13:12 Dibyendu Majumdar <[hidden email]> wrote:
On 23 November 2016 at 02:38, William Ahern <[hidden email]> wrote:
> On Wed, Nov 23, 2016 at 12:59:30AM +0000, Dibyendu Majumdar wrote:
>> This is just something I have been wondering about. I personally have
>> not yet found a use case for Lua's coroutines - the main reason being
>> that the resume has to be explicit. What would be more useful is if
>> the coroutine semantics could be harnessed to create an async/await
>> type solution as in C#. That is, can a solution be found to
>> automatically resume the coroutine when an event associated with a
>> 'yield' completes. As Lua is single threaded so the solution needs to
>> resume the coroutine within the same OS thread.
>
> For some definition of "automatic", this is actually quite trivial.
> Obviously it cannot be too automatic because Lua has a contract with C code.
> But this can be implemented quite transparently from the perspective of
> Lua-script space. The biggest caveat is that Lua objects are multithread
> safe.
>

Thanks for the detailed reply - much appreciated. Did you mean above
that Lua objects are not multi-thread safe?

>> I haven't really tried solving this but I thought it might be a useful
>> enhancement to Lua if a solution could be found. I imagine that a
>> background OS thread will be needed to monitor completion of events
>> and then some coordination with the VM will be necessary to resume
>> suspended coroutines, maybe whenever the VM does an operation that
>> requires system resources. In some ways the 'go' language works like
>> this - i.e. there is a background scheduler that swaps in suspended
>> goroutines to the thread whenever execution would otherwise pause.
>
> Goroutines work more like Lua coroutines than you'd think. While the kernel
> threads that goroutines execute on are preemptively scheduled, AFAIU the Go
> goroutine scheduler is cooperative. Control is usually passed between
> goroutines when doing reads and writs to a channel. The Go compiler also
> inserts checkpoints in compiled code, usually at function call points, to
> support garbage collection. Scheduling might also occur at those points.
>
> So while goroutines _feel_ preemptively scheduled, they're actually
> cooperative scheduled underneath the hood. It's why loops in Go code that
> don't do any I/O, polling, or message passing can hog the entire kernel
> thread and stop progress of other goroutines as well as the garbage
> collector.
>
> Lua's coroutines can be used in much the same way, you just need to
> implement a scheduler much like Go does. Lua gives you the tools to
> implement those patterns, you just need to build an application framework
> around to make it feel transparent.
>

I had a quick look at your project cqueues that presumably does this.
Would it be a good idea to port this to libuv so that Windows can be
supported as well (I understand cqueues only works on UNIX like
environments)?

Regards
Dibyendu


I don't understand concurrency at the level of most of you, but when I was curious about it and reading everything that I could get my hands on, it struck me that a dedicated IOCP-based library for Lua would be powerful.

To my limited understanding, IOCP is a thread safe message cue that notifies you when data is ready to be processed. There are facilities for signaling on specific messages, etc. I'm not sure why or how this is fundamentally different than other methods of managing concurrency. Most people who seem more educated to me inferred that the differences were so substantial that they preferred to use `poll` when implementing cross platform libraries

But IOCP seemed like a well-matched pattern for Lua and if there are indeed impedance mismatches between it and others, then a native library devoted to IOCP and all of its possibilities would be interesting.

The above is the perspective of an amateur. I'm interested to learn from someone with an informed opinion. :)

-Andrew