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 [email protected] On Sat, Dec 31, 2016 at 12:31 PM, Uther Pendragon <[email protected]> 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, <[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? _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
