weak reference proposal

Uther Pendragon uther420 at gmail.com
Sat Dec 31 17:31:14 UTC 2016


...additionally, I think the term "weak reference" is inaccurate for ipc
referencing...  I would describe that more as super-strong references than
weak...  resilient referencing.

On Dec 31, 2016 11:20 AM, <es-discuss-request at mozilla.org> wrote:

> If it were me, I would use a socket for ipc and use the socket as the weak
> map reference... Thus, when the socket was destroyed, and you get the
> SIGPIPE, free the socket reference, and it's referenced object should be
> cleared.  This should work, however if you have too many objects, then you
> might have to tree it out or something.
>
> I think the idea is a good one for library, I just don't think it's worth
> polluting the spec with...  thoughts?
>
> On Dec 31, 2016 11:20 AM, <es-discuss-request at mozilla.org> wrote:
>
> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>    1. Re: Weak Reference proposal (Isiah Meadows)
>    2. Re: Weak Reference proposal (Alexander Jones)
>    3. Re: Resource management (Isiah Meadows)
>    4. Re: Resource management (Isiah Meadows)
>    5. Re: Weak Reference proposal (Isiah Meadows)
>
>
> ---------- Forwarded message ----------
> From: Isiah Meadows <isiahmeadows at gmail.com>
> To: Steve Fink <sphink at gmail.com>
> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
> Date: Sat, 31 Dec 2016 08:48:19 -0500
> Subject: Re: Weak Reference proposal
> For my particular case, yes it is. Everything mirrored have globally
> unique IDs assigned to them, managed independently of the child
> process (in most cases), and the state is tied to the ID, not the
> value, so I only need a weak reference to clear the backing ID and its
> associated state. And reference cycles within the process are
> mitigated by the existing mark-and-sweep derivatives engines already
> use.
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
>
> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sphink at gmail.com> wrote:
> > On 12/27/2016 04:45 AM, Isiah Meadows wrote:
> >
> > The weak reference proposal hasn't seen a lot of activity, and I haven't
> > found much news elsewhere on it. What's the status on it?
> >
> > Where I'm building a language-integrated process pool in Node.js,
> complete
> > with shared "references" and async iterator support, I really badly need
> > weak references to avoid otherwise inevitable memory leaks across
> multiple
> > processes if the references aren't explicitly released. So far, my only
> > option is to take a native dependency (I have no other dependencies), but
> > that's very suboptimal, and it eliminates the possibility of porting to
> > browsers. So I really badly need language-level weak references.
> >
> >
> > Would weak references be enough to solve cross-process garbage
> collection?
> > How would you recover a cycle of references among your processes?
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
>
>
> ---------- Forwarded message ----------
> From: Alexander Jones <alex at weej.com>
> To: Isiah Meadows <isiahmeadows at gmail.com>
> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
> Date: Sat, 31 Dec 2016 14:23:38 +0000
> Subject: Re: Weak Reference proposal
> Please correct me Isiah/Steve - but I think the problem Steve is talking
> about is *cross-process* cycles. Without an inter-process protocol to
> express the referencing graph, or otherwise negotiate cycles for GC, you'll
> never have a way to reclaim them. Each side thinks the other side is still
> needing the resource.
>
> Cheers
>
> On 31 December 2016 at 13:48, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
>
>> For my particular case, yes it is. Everything mirrored have globally
>> unique IDs assigned to them, managed independently of the child
>> process (in most cases), and the state is tied to the ID, not the
>> value, so I only need a weak reference to clear the backing ID and its
>> associated state. And reference cycles within the process are
>> mitigated by the existing mark-and-sweep derivatives engines already
>> use.
>> -----
>>
>> Isiah Meadows
>> me at isiahmeadows.com
>>
>>
>> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sphink at gmail.com> wrote:
>> > On 12/27/2016 04:45 AM, Isiah Meadows wrote:
>> >
>> > The weak reference proposal hasn't seen a lot of activity, and I haven't
>> > found much news elsewhere on it. What's the status on it?
>> >
>> > Where I'm building a language-integrated process pool in Node.js,
>> complete
>> > with shared "references" and async iterator support, I really badly need
>> > weak references to avoid otherwise inevitable memory leaks across
>> multiple
>> > processes if the references aren't explicitly released. So far, my only
>> > option is to take a native dependency (I have no other dependencies),
>> but
>> > that's very suboptimal, and it eliminates the possibility of porting to
>> > browsers. So I really badly need language-level weak references.
>> >
>> >
>> > Would weak references be enough to solve cross-process garbage
>> collection?
>> > How would you recover a cycle of references among your processes?
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> ---------- Forwarded message ----------
> From: Isiah Meadows <isiahmeadows at gmail.com>
> To: Jamesernator <thejamesernator at gmail.com>
> Cc: "Raul-Sebastian Mihăilă" <raul.mihaila at gmail.com>, es-discuss <
> es-discuss at mozilla.org>
> Date: Sat, 31 Dec 2016 10:46:28 -0500
> Subject: Re: Resource management
> Certainly not optimal, though, and I'd rather it *not* become the
> primary idiom - it lacks the intent of a Python-like `with` statement.
> Also, `next`/`return` doesn't exactly mirror `__enter__`/`__exit__`
> from Python. What really happens with `for ... of` is closer to
> `next`/`next`, where the first call reports `{done: false, value:
> whatever}`, and the second `{done: true}`. It's more of a unusual pun
> than anything, a theoretical equivalence providing an unintuitive
> workaround.
>
> I would welcome a strict-mode-only modification to `with` that allows
> something like that, and adding `with await` for Promise-resolving
> equivalents.
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
>
> On Thu, Dec 29, 2016 at 11:05 PM, Jamesernator
> <thejamesernator at gmail.com> wrote:
> > The `for` loop approach works for synchronous resources as well actually,
> > there's nothing special about those `await`ed things e.g.
> >
> > ```js
> > const fs = require('fs')
> >
> > function* open(file, opts) {
> >     const fd = fs.openSync(file, opts)
> >     try { yield fd } finally { fs.closeSync(fd) }
> > }
> >
> > for (const fd of open("/path/to/file", {mode: "r+"})) {
> >     const bit = fs.readSync(fd)
> >     ...
> > }
> > ```
> >
> > I can definitely imagine a Python-esque `with` statement though (perhaps
> > with `Symbol.open/Symbol.close`) then you just use something like
> Python's
> > contextlib (https://docs.python.org/3.7/library/contextlib.html) utility
> > functions for converting generator based resources to
> > `Symbol.open/Symbol.close`.
> >
> > For now though the `for` loop approach is a relatively good workaround
> (as
> > `next/return` effectively emulate Python's `__enter__/__exit__`).
> >
> >
> >
> > On 30/12/16 04:17, Isiah Meadows wrote:
> >>
> >> But keep in mind it still doesn't cover two key issues:
> >>
> >> 1. Synchronous resources do in fact exist (primarily in Node). You
> >> need both for it to be effective.
> >> 2. Your suggestion isn't composable at all (like nearly every other
> >> callback-driven API), and it prevents returning from inside the block
> >> without the use of exceptions.
> >> -----
> >>
> >> Isiah Meadows
> >> me at isiahmeadows.com
> >>
> >>
> >> On Thu, Dec 29, 2016 at 9:05 AM, Raul-Sebastian Mihăilă
> >> <raul.mihaila at gmail.com> wrote:
> >>>
> >>> I agree, but note that a resolved promise is not the same as a
> fulfilled
> >>> promise (https://tc39.github.io/ecma262/#sec-promise-objects).
> >>>
> >>> On Thu, Dec 29, 2016 at 11:40 AM, Jordan Harband <ljharb at gmail.com>
> >>> wrote:
> >>>>
> >>>> You'd need to wrap the body of your `open` function in a try/finally,
> >>>> and
> >>>> do the `fsp.close` in the `finally` block - but otherwise that would
> >>>> certainly work, provided that the promise returned from `func` did
> >>>> actually
> >>>> settle (resolve or reject).
> >>>>
> >>>
> >>> _______________________________________________
> >>> es-discuss mailing list
> >>> es-discuss at mozilla.org
> >>> https://mail.mozilla.org/listinfo/es-discuss
> >>>
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
>
>
> ---------- Forwarded message ----------
> From: Isiah Meadows <isiahmeadows at gmail.com>
> To: J Decker <d3ck0r at gmail.com>
> Cc: "Raul-Sebastian Mihăilă" <raul.mihaila at gmail.com>, es-discuss <
> es-discuss at mozilla.org>
> Date: Sat, 31 Dec 2016 11:33:45 -0500
> Subject: Re: Resource management
> Not enough. Not looking for an `await` replacement, but something
> closer to Python's `with` statement or Java's `try`-with-resources.
> Or, if you want something
>
> Python: http://preshing.com/20110920/the-python-with-statement-by-example/
> Java: https://docs.oracle.com/javase/tutorial/essential/exceptions
> /tryResourceClose.html
>
> JavaScript's idioms tend towards Python, Java, C#, etc. in how
> resources are handled, so things like Ruby's `begin`-`ensure` wouldn't
> work as well (that was where I got my generator workaround from,
> actually, and as you can see, it's not exactly very obvious).
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
>
> On Fri, Dec 30, 2016 at 2:03 AM, J Decker <d3ck0r at gmail.com> wrote:
> > Just a shot; but something ilke deasync ?
> > https://www.npmjs.com/package/deasync
> >
> > it's not so much about ordering wait in the current code, but the current
> > code within outer code that's the issue somehow?
>
>
>
> ---------- Forwarded message ----------
> From: Isiah Meadows <isiahmeadows at gmail.com>
> To: Alexander Jones <alex at weej.com>
> Cc: "es-discuss at mozilla.org" <es-discuss at mozilla.org>
> Date: Sat, 31 Dec 2016 12:19:32 -0500
> Subject: Re: Weak Reference proposal
> That is a concern largely independent of my need for weak references
> (despite the relation). I can still implement a basic tiered
> mark-and-sweep without weak references, given I can already destroy
> things manually with just the ID. All I want is a way to implicitly
> call that destructor within the individual process.
>
> -----
>
> Isiah Meadows
> me at isiahmeadows.com
>
>
> On Sat, Dec 31, 2016 at 9:23 AM, Alexander Jones <alex at weej.com> wrote:
> > Please correct me Isiah/Steve - but I think the problem Steve is talking
> > about is *cross-process* cycles. Without an inter-process protocol to
> > express the referencing graph, or otherwise negotiate cycles for GC,
> you'll
> > never have a way to reclaim them. Each side thinks the other side is
> still
> > needing the resource.
> >
> > Cheers
> >
> > On 31 December 2016 at 13:48, Isiah Meadows <isiahmeadows at gmail.com>
> wrote:
> >>
> >> For my particular case, yes it is. Everything mirrored have globally
> >> unique IDs assigned to them, managed independently of the child
> >> process (in most cases), and the state is tied to the ID, not the
> >> value, so I only need a weak reference to clear the backing ID and its
> >> associated state. And reference cycles within the process are
> >> mitigated by the existing mark-and-sweep derivatives engines already
> >> use.
> >> -----
> >>
> >> Isiah Meadows
> >> me at isiahmeadows.com
> >>
> >>
> >> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <sphink at gmail.com> wrote:
> >> > On 12/27/2016 04:45 AM, Isiah Meadows wrote:
> >> >
> >> > The weak reference proposal hasn't seen a lot of activity, and I
> haven't
> >> > found much news elsewhere on it. What's the status on it?
> >> >
> >> > Where I'm building a language-integrated process pool in Node.js,
> >> > complete
> >> > with shared "references" and async iterator support, I really badly
> need
> >> > weak references to avoid otherwise inevitable memory leaks across
> >> > multiple
> >> > processes if the references aren't explicitly released. So far, my
> only
> >> > option is to take a native dependency (I have no other dependencies),
> >> > but
> >> > that's very suboptimal, and it eliminates the possibility of porting
> to
> >> > browsers. So I really badly need language-level weak references.
> >> >
> >> >
> >> > Would weak references be enough to solve cross-process garbage
> >> > collection?
> >> > How would you recover a cycle of references among your processes?
> >> >
> >> >
> >> > _______________________________________________
> >> > es-discuss mailing list
> >> > es-discuss at mozilla.org
> >> > https://mail.mozilla.org/listinfo/es-discuss
> >> >
> >> _______________________________________________
> >> es-discuss mailing list
> >> es-discuss at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20161231/e1c5238a/attachment-0001.html>


More information about the es-discuss mailing list