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
