DRAFT: Callback API

[Ambrevar]

Fixes #65.

For some reason Nyxt crashes on my machine when I load my local cl-webkit (unrelated to this change). I'll figure it out next week.

Feel free to test @aartaka

To do:

• Adapt can-execute-command-checked and message-replied-to.
• Add a similar macro for the uri-scheme-processed callback and adapt the code.
• Remove

(defvar callback-counter 0)
(defvar callbacks ())
(defstruct callback
  (id callback-counter :type number)
  web-view
  (function nil :type (or function null))
  (error-function nil :type (or function null)))

[Ambrevar]

On second thought, relying on CFFI to pass any callback, including closures, may have a drawback: it seems that the CFFI callbacks are never freed. Is this a CFFI limitation?

If so, it's problematic for Nyxt because it means that lots and lots of closures would capture data that can never be freed.

The current approach on master has the benefit of calling defcallback only on a some 2-3 hard-coded function, and it's we do clean up after use, thus freeing the closures.

To do:

• Ask CFFI if their callbacks are ever freed.
• If yes, then this patch is good.
• If no, then I suggest we implement an intermediary approach: define 1 hardcoded callback for g-async-result. This hardcoded callback would accept a closure which is stored in callbacks and freed after it's called.

[aartaka]

SBCL callbacks are not freed, as far as I understand by

;;; FIXME: This call assembles a new callback for every closure,
;;; which sucks hugely. ...not that I can think of an obvious
;;; solution. Possibly maybe we could write a generalized closure
;;; callback analogous to closure_tramp, and share the actual wrapper?
;;;
;;; For lambdas that result in simple-funs we get the callback from
;;; the cache on subsequent calls.
(defmacro alien-lambda (result-type typed-lambda-list &body forms)
  (multiple-value-bind (specifier lambda-list)
      (parse-callback-specification result-type typed-lambda-list)
    `(alien-callback ,specifier (lambda ,lambda-list ,@forms))))

[Ambrevar]

Let's go for the intermediary solution then?

[aartaka]

Yes!

[jmercouris]

Agreed on the intermediary solution.