weak reference proposal

Isiah Meadows isiahmeadows at gmail.com
Sat Dec 31 18:19:48 UTC 2016

There's a problem with that idea: I've got one socket per process, but
I can have anywhere from 0 to N shared references per process that I
still have to track. And also, the shared references can be exposed to
any other child within other pools, and even released by the child it
was created in afterwards. Consider this:

1. Child 1 creates shared reference.
2. Child 1 sends reference to parent.
3. Parent receives reference.
4. Child 1 releases reference.

At this point, the parent has already received the reference it
*didn't* create, but the child released the reference itself locally.
Therein lies the problem.


Isiah Meadows
me at isiahmeadows.com

On Sat, Dec 31, 2016 at 12:31 PM, Uther Pendragon <uther420 at gmail.com> wrote:
> ...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?

More information about the es-discuss mailing list