edbrowse-dev - development list for edbrowse
 help / color / mirror / Atom feed
From: Chris Brannon <chris@the-brannons.com>
To: Edbrowse-dev@lists.the-brannons.com
Subject: Re: [Edbrowse-dev] gc rooted
Date: Sat, 25 Jan 2014 09:20:42 -0800	[thread overview]
Message-ID: <871tzwou51.fsf@mushroom.PK5001Z> (raw)
In-Reply-To: <20140025114736.eklhad@comcast.net> (Karl Dahlke's message of "Sat, 25 Jan 2014 11:47:36 -0500")

Karl Dahlke <eklhad@comcast.net> writes:

> The guide talks about local variables, parameters, returns,
> heap, but nothing about global or static.

Ok, here's my suggestion.
Actually I've been implementing it along with my other work on html.cpp
and buffers.c.
Let's get rid of the global jwin altogether.
It duplicates the data in cw->jsw.  There's always going to be
a current edbrowse window, and that window's jsc and jsw should never go
out of sync with the globals jcx and jwin.
Instead of the globals, let's pack all of this JS stuff into an opaque
struct on the heap, with a pointer stored in ebWindow, like so:

/* file eb.h */
/* Forward decl, fully declared in js.h. */
struct ebJSState;

struct ebWindow {
...
    struct ebJSState *jsstate;
/* Struct is opaque outside js-related files. */
};

/* File js.h */
struct ebJSState {
    JSContext *jcx;
    jS::Heap<JSObject *> jwin;
    JS::Heap<JSObject *> jdoc;
};

So now jdoc and jwin are rooted.

We could keep using the jdoc and jwin globals, and use JS_AddObjectRoot
to root them, but I think the opaque struct is the safest bet.  It also
eliminates void pointers.
The jcx global is ok, but I'd argue for getting rid of it as well, since
it just duplicates the JSContext * from the current window.


-- Chris

  reply	other threads:[~2014-01-25 17:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-25 16:47 Karl Dahlke
2014-01-25 17:20 ` Chris Brannon [this message]
2014-01-26 23:41 ` Adam Thompson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871tzwou51.fsf@mushroom.PK5001Z \
    --to=chris@the-brannons.com \
    --cc=Edbrowse-dev@lists.the-brannons.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).