Re: event loop and timers

On Sun, Sep 1 2024 at 06:56:19 PM +0000, Peter Harris <[email protected]> 
wrote:
> Something like (pseudocode):

 That's sweet! if I understand it correctly. Assuming that the 
'process_timers()' are the user interface timers the program creates, 
not 'signal()', effectively bypassing extra signals.
 Now two questions. I hadn't thought about a user possibly doing a 
xcb_*reply function within their supplied timer handler. Given I hadn't 
but barely used replies. And since you brought it up, 
xcb_poll_for_queued_event() before poll() sounds perfect for checking 
if an event/reply occurred while doing process_timer() with maybe an 
elapsed time use for xcb_poll_for_queued_event() subtracted from 
timeout before and/or if should run poll(), given timeout could 
approach 0.
 First question, did I grasp your concept correctly? Second, is the 
addition of queued_event understood? because to find info on these 
subjects seems scarce to nil.
 Hopefully I got right, but excited to try/fail on the concept either 
way. My original proposed concept with 'has_timers' = false yielded a 
great result of finding a XCB_DESTROY_NOTIFY response_type, since the 
original loop got exited by a XCB_CLIENT_MESSAGE, used to 
WM_DELETE_WINDOW which destroyed the window and exited the loop prior 
XCB_DESTROY_NOTIFY. My conversion to XCB only has one window for 
designing/testing, rather than multiple ones. And am excited how well 
XCB shines above what I had, and what seems to be unbounded creation 
potential.
 Thank you mega-much, Peter, this is greatly greatly appreciated! And 
does solve the busy-loop I wanted to avoid but couldn't see a way out.
Steve