Re: A Batteries API specification (was Re: LuaDEAL - Lua DEad Alive Libraries)

[pocomane <pocomane_7a@...>]

On Thu, Jan 30, 2020 at 9:52 AM Sean Conner wrote:
>   Generally under POSIX, if it has a file handle, it can be used for event
> processing.  More and more modern POSIX systems are making non-file objects
> available via file descriptors (like signals under Linux).  Right now, I"m
> aiming more for a "widely supported event processing" model, which now is
> mostly file-related.

Ok. I was hoping it was a more general purpose "Event notification
system", but it is fair enough to start with the most common cases.

> > I am not discussing the implementation here, if there is the need for
> > a "Fake file descriptor" internally, it can be done [1]. In this
> > spirit I would substitute "File descriptor" and "_tofd" with something
> > else.
>
>   I'm open to suggestions.  I don't like "_tofd" myself, but I'm not sure
> what a better name would be.

The fact is that a file descriptor does multiple different things (it
both controls the stream and provides the stream) so no name will be
satisfactory. E.g. for the monitoring you could speak of "Event
source" (_eventsource()), but it is weird when you realize that it is
the same object you write to. Maybe it is better to make the reference
completely opaque at this point,  with somthing like "_rawresource()".

>         events = nfl.SOCKETS:events()
>         for _,event in ipairs(events) do
>           event.obj(event)
>         end

It seems to me that all the examples would be practically identical
with the return format I proposed. But it let you to write also

monitor:insert(sock1, 'rw')
events = set:events()
if events[sock1] and events[sock1].read then
  -- do something
end

that it is a more direct than to loop on a list and to check if the
object is the wanted one.

However for me this is a very minor issue.

> > Moreover, I think that keeping it simple is more valuable than your
> > trick to substitute an optional var to Obj. If a user code really need
> > it, it can keep the map in a table by its own.
>
>   Honestly, I didn't find the current implementation all that difficult, and
> I did it four different times (select(), poll(), epoll() and kqueue()).

I think that also a very small over-structure should be avoided if its
implementation in the user code has the same complexity:

myhandler[obj] = function()
  --...
end

events = nfl.SOCKETS:events()
for _,event in ipairs(events) do
    myhandler[event.obj](event) -- instead of event.obj(event)
end

> > [1] However, probably every lua-side standard specification will need
> > some c-side specification. And probably, some internal details have to
> > be exposed there.
>
>   What did you have in mind?
>

Nothing, if you are thinking just to file descriptors. But I would
like to see a "Event Notification Module" (ENM) that could in
principle work with any kind of event. Something like libuv, but much
simpler, and extendable by other C modules.

I do not have any proposal, neither for the API. If I have to put
together something, I would say to register a callback somewhere, e.g.
in an hypothetical Gamepad Module (GM):

// pseudo-C
enm_register_scheme("gm", my_gm_callback);

Then in lua you could:

local evsrc = enm.newmonitor"gm://1"
local s = enm.newpollset()
s:insert(evsrc, 'r') -- my_gm_callback is called
s:insert(enm.newmonitor"tcp://aserver:1234", 'r')
local event = s:wait(0.1) -- my_gm_callback is called (the tcp handler is too)

How does s:wait work? If there were just files and sockets, it would
be a select/poll/whatever. But with the GM? Thread pools and worker
queues? I think the important here is just to specify a C API that let
enm_wait to act as it was a select/poll/whatever, delegating to
my_gm_callback the raw work.

Sorry for the very raw state of my ideas.

Finally, I think it is important to start stating what should contain
the standard library. E.g.:
- File system interaction
- Socket
- Event notification module
- Sub-process spawning and minimal interaction (environment variables,
standard io stream)
- Crypto/TLS (I would prefer an embeddable library without external
so/dll, like bearssl)
- Real multithreading (probably it needs a message parsing library too)
- Parsing (lpeg? regex?)
- Object oriented programming

Other (?):
- Logging
- Audio
- GL/glext/GLFW/image-loading
- What else?