weak reference proposal

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


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/b3455128/attachment-0001.html>


More information about the es-discuss mailing list