This adds a few details which I would have found welcome while working on my frontend scheduler. --- docs/implementing-new-frontend.md | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/docs/implementing-new-frontend.md b/docs/implementing-new-frontend.md index 4bda47af0..76d73e94b 100644 --- a/docs/implementing-new-frontend.md +++ b/docs/implementing-new-frontend.md @@ -126,11 +126,26 @@ The only mandantory operation in this table is schedule. When schedule is called the frontend must arrange for the passed callback to be called with the context parameter after a number of -miliseconds. +miliseconds. All combinations of callback & context are only to be +scheduled once, the scheduler should remove any existing callbacks +for a given tuple before scheduling anew. The scheduler will be +called with a timeout less than zero to have any previously +scheduled callbacks removed. This callback is typicaly driven through the toolkits event loop and it is important such callbacks are not attempted from an operation. +There are some important factors to consider for your event loop: + +- When a callback is due, you must remove it from your schedule + *before* calling it. +- You should run pending callbacks before calling `fetch_fdset` + (which is something you should call, by the way). + +Failure to uphold these criteria will unleash eldritch horrors upon +your frontend and waste your entire morning trying to figure out +bizzare race conditions. + ### window operation table The window operations (poorly named as already mentioned) are where -- 2.33.0 _______________________________________________ netsurf-dev mailing list -- netsurf-dev@netsurf-browser.org To unsubscribe send an email to netsurf-dev-le...@netsurf-browser.org
