[Webkit-unassigned] [Bug 184041] [GLIB] Add JSCWeakValue to JavaScriptCore GLib API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=184041

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcatanzaro at igalia.com
 Attachment #336585|review?                     |review+
              Flags|                            |

--- Comment #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
Comment on attachment 336585
  --> https://bugs.webkit.org/attachment.cgi?id=336585
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=336585&action=review

> Source/JavaScriptCore/API/glib/JSCWeakValue.cpp:193
> +        g_signal_emit(weakValue, signals[CLEARED], 0, nullptr);

I'm hesitant about this signal. Wouldn't it be better for the user to pass in a GWeakNotify to be called instead of using a signal? The signal makes it hard to use in performance-sensitive code.

I even thought about suggesting that JSCWeakValue be a GBoxed or even an opaque struct instead of a GObject, but I suppose since JSCValue is a GObject it's better to parallel that.

> Source/JavaScriptCore/API/glib/JSCWeakValue.cpp:260
> +            static_cast<GParamFlags>(WEBKIT_PARAM_WRITABLE | G_PARAM_CONSTRUCT_ONLY)));

Might want to add a warning comment as to why it must never be made readable.

> Source/JavaScriptCore/API/glib/JSCWeakValue.cpp:299
> + * Returns: (transfer full): a new #JSCValue or %NULL if @weak_value was cleared.

I was worried about the JSCValue being destroyed on the GC thread, but I suppose that cannot ever happen because you take a lock here and return a strong ref. That's the main thing I was looking to see in this review. Good.

> Source/JavaScriptCore/API/glib/JSCWeakValue.h:54
> +    void (*_jsc_reserved0) (void);

It has a signal, why not expose it here?

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180327/135e31b6/attachment.html>