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-leave@netsurf-browser.org
No comments:
Post a Comment