Hi Etienne,

The reason why there is no poll/select implementation is that the systems that we support all have something better then poll/select, which can be used instead. So yes, “no interest” would fit. The main factor is of course that we have no access  to those commercial Unix distributions that have neither of  IOCP,epoll, kevent or ports

The  notification property that we want to have here is that, once there is some data on a socket coming from client, the socket is returned, and is taken out of the “poll set”. Socket returns to the “poll set” once command(e.g SQL query , or anything else that client-server protocol understands) is fully processed. We’d like to avoid multiple notifications on a socket,  until client command is fully processed, otherwise different threads from the pool will try to process client’s command at the same time.

This is the only thing we need, and this is something that poll/select do not provide.

As for Solaris ports –

existing Solaris implementation is based on ports, and as far as I could test, it had this one-shot behaviour, which is that we need, I.e port_get() only returns a single event, and then there must be a new port_associate() to reenable the socket/return it to “poll-set”. The documentation confirms this observation

“Objects of type PORT_SOURCE_FD are file descriptors. The event types for PORT_SOURCE_FD objects are described in poll(2). At most one event notification will be generated per associated file descriptor. For example, if a file descriptor is associated with a port for the POLLRDNORM event and data is available on the file descriptor at the time the port_associate() function is called, an event is immediately sent to the port. If data is not yet available, one event is sent to the port when data first becomes available.”

I read somewhere IOCP would exist on AIX, so I hoped existing Windows code in threadpol_generic.cc would be of some help, if someone eventually ports that to AIX . Although, admittedly Windows code,  uses a trick to reading zero bytes in ReadFile/WSARecv, which effectively translates asynchronous IO to “poll-like” notification modes.

From: GUESNET, ETIENNE (ext)
Sent: Tuesday, 17 September 2019 14:13
To: maria-developers@lists.launchpad.net
Subject: [Maria-developers] Implementation of Threadpool

Hi,

I am implementing a threadpool system to AIX. The AIX equivalent of epoll / kqueue on AIX is pollset (and IOCP, but partial implementation only). However, pollset has only a level-trigger mode and MariaDB needs edge-trigger (see comments of sql/threadpoll_generic.h file). Adding a pollset support in MariaDB would be difficult, and probably not so efficient, as we need to simulate the edge-trigger behavior.

Obviously, AIX has poll and select support. MariaDB has not. Is there a reason to don’t implement threadpoll through poll or select? No interest? Performance issues?

MariaDB currently works on AIX without threadpool; in term of efficiency, do you know what can be obtained using threadpool with poll/select or a more modern solution?

As far I know, SunOS/Solaris/Illumos threadpoll system (called “port”) is also level-trigger only, but I do not find specific functions to manage this.

Thanks!

Etienne Guesnet.