Low priority - thoughts on file descriptor event loop callbacks


First, I would like to give thanks to the team behind GLFW. I’ve used it on and off over the years for personal projects. It works very well and saved me the work of navigating the native apis.

I have a question about providing an API to the main event loop for file descriptor events for the GLFW maintainers.

I would like to move to a mode where the entire app is event driven vs. polled/display update driven. In order for that to work, I would need to know about other events (timers, sockets, etc.) besides the GUI events. I would also like to avoid threading, since this would add a lot more complexity.

Currently, I have the typical GLFW event-loop with a unix ‘poll’ call for my socket descriptors at the end of the event-loop. I don’t have that many descriptors, so a ‘poll’ is fine vs an ‘epoll’.
After doing the socket processing, the the main event loop continues.

The latency is not really a problem (processing takes microseconds and the app is not real-time). The app consumes CPU and power while idling. To be clear, I am fine with how things are as is. Not having to deal with the platform APIs has been great.

Still, I thought I would pose the question to learn about the possibility.

If GLFW provided an API that allowed setup/teardown of a callback for an operating system handle and some events (Read, Write, Error), that would be sufficient.
Ideally, the callbacks would happen on the main thread.

As a non-implementer, I suspect that this has been thought about and there are some negatives to implementing such a thing.

Some possible downsides:

  • more API == more area == more testing and support
  • platform issues: various unixes and Windows are too different
  • the current system would need a lot of work to accommodate extra descriptors
  • other?

So, what are the thoughts about something like this?


Hi @drudru,

GLFW is designed to be very narrowly focussed on it’s goal of being a cross platform window library for OpenGL ES and Vulkan development on the desktop. Indeed, functionality present in earlier versions of GLFW which does not directly focus on this goal has been removed.

So I do not think adding more general purpose events to GLFW would be reasonable.

Such a library could be built on top of GLFW, and if it was open sourced other people might contribute to it’s development.

Hi Doug, thanks for your response. This is a very reasonable position.

(BTW, I apologize for the late reply, I didn’t see this until just now)