Re: event loop and timers
Carlo Wood <[email protected]> Tue, 3 Sep 2024 11:49:56 +0200
| Newsgroups | gmane.comp.freedesktop.xcb |
|---|---|
| Message-ID | <[email protected]> |
You might want to consider using my tool set, that was written for high performance applications. It features a thread pool with a fixed number of pre-started threads and will never create a new thread. You can run millions of timers at the same time without any noticeable overhead. See https://carlowood.github.io/statefultask/ for some preliminary documentation. It also comes with xcb support (https://github.com/CarloWood/xcb-task) which can be used to hand off the X socket of xcb to the I/O event loop thread of statefultask (it has a single thread that does all calls to epoll for any fd events). On Sun, 01 Sep 2024 09:30:22 -0400 Steven J Abner <[email protected]> wrote: > Having an issue with using timers with 'beginner loop'. From > scratch, created a window that handles events, with display port > rectangles within the window. So basically one window with one main > context or draw surface, and multiple 'dp rectangles' within. When > resizing a window, these 'dp rectangles' adjust their size or > 'configure'. A 'dp rectangle' can also have a grip for resizing. This > can be better visualized as the window's context being a desktop > background, and the 'dp rectangle' as a window being resized on said > desktop. When dragging the grip, the resizing can stutter or jump > positions in a less than smooth fashion. The solution is a timer to > fire off XCB_EXPOSE after an accumulation of invalid bounding areas > rather than XCB_EXPOSE on every XCB_MOTION_NOTIFY. > Using a timer with sigev_notify = SIGEV_THREAD works perfectly in > this situation, but spams the heck out of creating a thread, and > makes debugging almost useless because of reporting the million > thread creations. > Using a timer with sigev_signo = SIGALRM, or SIGUSR1 only partially > works until crash caused xcb_send_request_with_fds64 locks, or > forever wait. > My question then becomes: can I parse 'event->response_type' > 0x7F > to intercept signals or will this algorithm be a possible untested > solution: > > while (run_loop) { > while ( !has_timers && (event = xcb_wait_for_event(connection)) ) { > parse_event: > } > while (has_timers) { > /* run timers until event, run event return, until no timers */ > _timer_update() > if ((event = xcb_poll_for_event(connection)) != NULL) > goto parse_event; > } > } > > static void > _timer_update() { > > clock_gettime(CLOCK_MONOTONIC, &ts); > if (elapsed) { > call handler(); // may delete timer > if (id) update next firing > else if (--timer_count == 0) has_timers = false; > } > } > > Any insight would be greatly appreciated! > Steve > >