...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, <[email protected]> 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, <[email protected]> wrote: > > Send es-discuss mailing list submissions to > [email protected] > > 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 > [email protected] > > You can reach the person managing the list at > [email protected] > > 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 <[email protected]> > To: Steve Fink <[email protected]> > Cc: "[email protected]" <[email protected]> > 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 > [email protected] > > > On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <[email protected]> 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 > > [email protected] > > https://mail.mozilla.org/listinfo/es-discuss > > > > > > ---------- Forwarded message ---------- > From: Alexander Jones <[email protected]> > To: Isiah Meadows <[email protected]> > Cc: "[email protected]" <[email protected]> > 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 <[email protected]> > 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 >> [email protected] >> >> >> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <[email protected]> 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 >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> > >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> > > > > ---------- Forwarded message ---------- > From: Isiah Meadows <[email protected]> > To: Jamesernator <[email protected]> > Cc: "Raul-Sebastian Mihăilă" <[email protected]>, es-discuss < > [email protected]> > 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 > [email protected] > > > On Thu, Dec 29, 2016 at 11:05 PM, Jamesernator > <[email protected]> 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 > >> [email protected] > >> > >> > >> On Thu, Dec 29, 2016 at 9:05 AM, Raul-Sebastian Mihăilă > >> <[email protected]> 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 <[email protected]> > >>> 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 > >>> [email protected] > >>> https://mail.mozilla.org/listinfo/es-discuss > >>> > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > > > > > > > > ---------- Forwarded message ---------- > From: Isiah Meadows <[email protected]> > To: J Decker <[email protected]> > Cc: "Raul-Sebastian Mihăilă" <[email protected]>, es-discuss < > [email protected]> > 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 > [email protected] > > > On Fri, Dec 30, 2016 at 2:03 AM, J Decker <[email protected]> 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 <[email protected]> > To: Alexander Jones <[email protected]> > Cc: "[email protected]" <[email protected]> > 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 > [email protected] > > > On Sat, Dec 31, 2016 at 9:23 AM, Alexander Jones <[email protected]> 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 <[email protected]> > 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 > >> [email protected] > >> > >> > >> On Tue, Dec 27, 2016 at 4:34 PM, Steve Fink <[email protected]> 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 > >> > [email protected] > >> > https://mail.mozilla.org/listinfo/es-discuss > >> > > >> _______________________________________________ > >> es-discuss mailing list > >> [email protected] > >> https://mail.mozilla.org/listinfo/es-discuss > > > > > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
