Hello,
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?
dru