LibreFrame design choices

General
1

Since this is an off-topic in the original thread, I start a new one.

I have a question regarding deploying epoll(). What was the reason for?

  • epoll() is a Linux thing. Choosing it precludes Windows and BSD. As far as I know they do not have epoll(). Windows has WSAPoll which is reportedly broken.
  • From what I read about performance, reports vary, from big difference to socket select to marginal.
  • epoll() can handle more sockets, but having 1000 or so limit per thread is not an issue in my view.
  • What is worse is that according to some accounts epoll() is broken and requires non-trivial workarounds to avoid subtle errors. I don’t know how credible is this, though.

If anybody wanted to die on this hill, then in my view a better solution would be to patch GNAT.Sockets for Linux and implement its socket select via epoll().

Another issue is SQLite. In my view persistence must be 100% Ada and non-SQL and in any case if SQL then some mature RDBMS.

And finally, what was so wrong with Gnoga that required a total redesign? I mean, Ada community is small, resources better be allocated sparingly


2

Portability is not everyone’s highest priority. If you only expect an application to run in one environment, it is a waste of effort. Even if you plan to support multiple platforms, you have to start somewhere. BSD’s kqueue is similar enough to epoll that porting between them is not too difficult.

select() requires you to pass the whole socket list to the kernel in every call. The kernel then needs to iterate through the entire list checking for sockets with events waiting.

With epoll, you use epoll_ctl() to add/modify/delete sockets in a set the kernel manages. epoll_wait() only needs to return a pointer to a list of ready sockets to userspace. The kernel simply appends to the ready list when an event happens, no need to iterate through sockets without events pending.

There are more than 1000 clients on the internet. Your requirements may vary, but supporting massive concurrency is table stakes these days.

epoll had some scalability issues with coordination of multiple threads in the past, but this is no longer the case with the addition of EPOLLEXCLUSIVE and SO_REUSEPORT support in the Linux kernel.

the GNAT.Sockets interface is only a thin wrapper around select(). The Check_Selector procedure expects you to pass the whole interest list with every call. This would eliminate any performance benefit from using epoll.

That’s a nice idea, but here in the real world, developing a new database is a major effort and likely of little benefit when you have a mature, well tested, well understood codebase like SQLite available.

1 Like
3

Hello Dmitry,

Here some answers


EPOLL

epoll is not a linux Thing. GitHub - piscisaureus/wepoll: wepoll: fast epoll for windows⁧ 🎭 GitHub - smallnest/epoller: epoll implementation for connections in Linux, MacOS and Windows Everything will be done to ensure the best possible performance, whatever the platform, we’ll adapt to the best API available.

Epoll’s effectiveness fully apparent after 10K req/s.

There’s even an API that outperforms epoll, It might be Io_uring but I’m not qualified to talk about it. Xavier is in charge of this part.

LibreFrame is looking for the best compromises. It’s not about performance for its own sake. But we know, as Web professionals (after all, we’re originally hosting providers), that you shouldn’t compromise too much in this area.

PLATFORMS

Unlike v22, LibreFrame will be multi-platform. Depending on the OS, API calls will differ, depending on what is available.

SQL

We totally agree that SQL is a really bad idea, whose implementations are incompatible with each other, whose standard isn’t even public (you have to find a 2011 draft on the net).

If anything should be object, it should be databases.

I discussed this with StĂ©phane Carrez at AEiC 2025, as he created an ORM for AWA. The result of our discussions was mixed and we don’t have a straight answer.

For the time being, reality being what it is (SQL is everywhere), LibreFrame will (probably) take over David’s Gnoga code, extending it to Po
stgreSQL and probably Firebird too.

GNOGA

We don’t see Gnoga as something to be knocked down, but as an essential step in our quest for what motivates us: to make the development of graphics applications truly more productive. David Botton, who designed Gnoga in 2016 (from memory), had some really great ideas.

v22.Gui, a layer above Gnoga, has made development more productive. LibreFrame is still a notch above and should represent a first achievement.

The important thing is that this approach has already been tested with a real industrial application. And its effects have been measured. That’s what prompted us to continue.

Some elements here: https://www.libreframe.com/wp-content/uploads/sow-20250608-AEiC2025-presentation.pdf

All the best from Oleron Island.

4 Likes
4

This is not epoll(). A Windows epoll() would require developing a driver in order to deal with it in the kernel space as Linux does. There is no need for that under Windows, because it natively supports asynchronous I/O from the beginning.

What the implementation actually does, is Windows’ standard overlapped I/O interfaced as epoll(). You can turn it around what about “porting” overlapped I/O to Linux instead? :grinning:

In any case, there is nothing that forces you to use a user-level C code to do Windows overlapped I/O or whatever BSD might have (likely nothing usable :grinning:) or VxWorks etc. It can easily be done in Ada and with rather more reasonable interface working across all targets.

I would use GNAT.Sockets for such an interface, as I said before.

But first, I would benchmark the performance myself. I have strong suspicion that socket implementations may rely on the same kernel facilities, e.g. overlapped I/O under Windows and the only difference would be in managing the socket sets = marginal.

5

The developers of SQLite would argue with your characterization of it as not “mature”. For what it provides, namely a simple, robust, single-file database, it is quite mature. You should read about the level of QA testing that they use – it is quite impressive: How SQLite Is Tested

7 Likes