This is something I've discovered like 18 months ago or so, but I had local workaround that was ok at the time.
Some context: I have a pet project, where I'm writing UI toolkit for Linux in swift. It was fairly obvious for me to use RunLoop as, you know, run loop :) In order to integrate with X11 window system, both xlib and xcb expose the file descriptor which is used by X11 to send events to client. CFRunLoop on Linux is using epoll file descriptors to wait on events from eventfd or timerfd to provide same functionality as it does on Darwin. For example,
_wakeUpPort is eventfd. When run loop needs to be awaken, code writes 8 integer bytes with value of
1 to this fd. Then code reads those exact same 8 bytes in order to "reset" this file descriptor.
The issue I see is that when I'd like to listen to that file descriptor from xlib or xcb in CFRunLoop via creating CFRunLoopSource from CFRunLoopSourceContext1, the code that "reads 8 bytes" from file descriptor is also being executed on this file descriptor. Which, you know, makes data provided from X11 malformed. It actually detects that and aborts application execution.
All of that was ok, because I used
FileHandle from Foundation to watch on this file descriptor via
waitForDataInBackgroundAndNotify. But now I am starting to work on integration with libinput which has a very critical limitation: event received from libinput has to be handled as soon as it arrived. With this limitation I can not proceed with the project and looking for help how to mitigate the issue. I've filed a task SR-14920 and attached a sample project to reproduce the issue. I've also started to poke around possible fixes, but this is wrong and will disable timers handling by runloop. Basically, i wanted to ask for opinions from community before i proceed in trying to change anything.