[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: C++ religious war (was: llua Higher-level C API for Lua)
- From: Coroutines <coroutines@...>
- Date: Fri, 21 Mar 2014 15:47:22 -0700
On Fri, Mar 21, 2014 at 2:38 PM, Sean Conner <sean@conman.org> wrote:
> It was thus said that the Great Andrew Starks once stated:
>>
>> poll/select
>> A "poll" or "select" library that used the native environment's
>> best-equivelent. I know that this is hard, but if one is trying to
>> achieve the ability to catch file / socket i/o, there should be a
>> library that other library authors use. LuaSocket does this (as well
>> as sleep), and even makes it easy to integrate with other libraries.
>> But it is not insignificant that I need to load LuaSocket to use it
>> and it only supports select on Windows. IO Completion ports would be
>> much better.
>
> I have a specific module that wraps select() [1] (very old systems,
> possibly Windows)/poll() (there rest of the POSIX universe)/epoll() (Linux
> only), depending upon the support. The Lua visible API is the same, but it
> does expose some additional functionality if it exists (epoll() does both
> level and edge triggered events for instance). It works for Unix systems; I
> do not have a Windows system for testing.
>
> One downside, it requires file handles (ints), not FILE objects. I needed
> this primarily to work with sockets (another module I have [2]) so to avoid
> polluting my select module with implementation details of that, I decided to
> punt and leave it with file handles.
>
> IO Completion ports only exist on Windows---they use a different model of
> programming than Posix, and sometimes, the two have a hard time meshing (for
> portability).
>
> -spc
>
> [1] https://github.com/spc476/lua-conmanorg/blob/master/src/pollset.c
>
> [2] https://github.com/spc476/lua-conmanorg/blob/master/src/net.c
>
>
Just popping in to say IOCP on Windows is like POSIX AIO in that you
request an operation be completed and are notified when it has been.
With things like select() or epoll() you are notified when a socket is
ready for reading, but with IOCP or AIO you are notified when the
buffer you pointed the OS at has been filled with the data you wanted
to read. IOCP/AIO should mean less waiting for events to occur
because they can handle the two-step process of reading data from and
filling a buffer, where usually your program does that. (This is just
an example -- the other side would be telling IOCP/AIO to write data
from a buffer to a socket when it can.) Usually you would
select()/poll()/epoll()/kqueue() to be notified when you can write
from the buffer out, but the OS can do this faster (which is why
people want to like IOCP/AIO). The only one nobody seems to like is
real-time signal IO. Dude, fuck SIGIO.
- References:
- Re: C++ religious war (was: llua Higher-level C API for Lua), Isaac
- Re: C++ religious war (was: llua Higher-level C API for Lua), Jeremy Ong
- Re: C++ religious war (was: llua Higher-level C API for Lua), steve donovan
- Re: C++ religious war (was: llua Higher-level C API for Lua), Roberto Ierusalimschy
- Re: C++ religious war (was: llua Higher-level C API for Lua), Hisham
- Re: C++ religious war (was: llua Higher-level C API for Lua), steve donovan
- Re: C++ religious war (was: llua Higher-level C API for Lua), Roberto Ierusalimschy
- Re: C++ religious war (was: llua Higher-level C API for Lua), Jeremy Ong
- Re: C++ religious war (was: llua Higher-level C API for Lua), steve donovan
- Re: C++ religious war (was: llua Higher-level C API for Lua), Andrew Starks
- Re: C++ religious war (was: llua Higher-level C API for Lua), Sean Conner