Garbage collection in generators

[Benjamin Gruenbaum]

> C++ RAII and Python refcounting are completely different: they are
precise, prompt, predictable, and deterministic.

C++ RAII is indeed amazingly deterministic - as are languages with built in
reference counters like Swift.

Python refcounting certainly is not since it performs cycle detection. Had
it not performed cycle detection (mark & sweep as far as I recall in
CPython). PyPy and other implementations have fuller garbage collection
systems
https://pypy.readthedocs.org/en/release-2.4.x/garbage_collection.html

It appears that Python GC with cycle detection predates the change in
generators that gave them "finalization" (At least 2.2 where the change in
Generators came in 2.5).

Python does however have destructors. They are weak (certainly weaker than
C++ destructors). Python also however has context management through the
`with` statement like C# (using) and Java (try-with-resource).
Interestingly - they even have async/await aware disposers (async disposers
- added in 3.5).






On Wed, Feb 17, 2016 at 4:54 PM, Mark S. Miller <erights at google.com> wrote:

> Everyone, please keep in mind the following distinctions:
>
> General GC is not prompt or predicable. There is an unspecified and
> unpredictable delay before anything non-reachable is noticed to be
> unreachable.
>
> JavaScript GC is not specified to be precise, and so should be assumed
> conservative. Conservative GC may never notice that any particular
> unreachable thing is unreachable. The only reliable guarantee is that it
> will never collect anything which future computation will reach, i.e., it
> will not cause a spontaneous dangling reference. Beyond this, it provides
> only unspecified and, at best, probabilistic and partial cleanup.
>
> C++ RAII and Python refcounting are completely different: they are
> precise, prompt, predictable, and deterministic.
>
>
>
> On Wed, Feb 17, 2016 at 12:59 AM, Benjamin Gruenbaum <benjamingr at gmail.com
> > wrote:
>
>>
>>
>> On Wed, Feb 17, 2016 at 10:51 AM, Andreas Rossberg <rossberg at google.com>
>> wrote:
>>
>>> On 17 February 2016 at 09:40, Benjamin Gruenbaum <benjamingr at gmail.com>
>>> wrote:
>>>
>>>> If you starve a generator it's not going to get completed, just like
>>>>> other control flow won't.
>>>>>
>>>>
>>>> I'm not sure starving is what I'd use here - I definitely do see users
>>>> do a pattern similar to:
>>>>
>>>> ```js
>>>> function getResults*() {
>>>>      try {
>>>>          var resource = acquire();
>>>>          for(const item of resource) yield process(item);
>>>>      } finally {
>>>>          release(resource);
>>>>      }
>>>> }
>>>> ```
>>>>
>>>
>>> Yes, exactly the kind of pattern I was referring to as "bogus forms of
>>> resource management". This is an anti-pattern in ES6. It won't work
>>> correctly. We should never have given the illusion that it does.
>>>
>>
>> What is or is not an anti-pattern is debatable. Technically if you call
>> `.return` it will run the finally block and release the resources (although
>> if the finally block itself contains `yield` those will also run).
>> Effectively, this will have the same sort of consequences that
>> "acquire()" and "release()" had to begin with - so I would not say it makes
>> things worse but I definitely agree that it creates a form of false
>> expectation.
>>
>> Still - I'm very curious why languages like Python have chosen to call
>> `finally` blocks in this case - this was not a hindsight and according to
>> the PEP. They debated it and explicitly decided to call `release`. I'll see
>> if I can email the people involved and ask about it.
>>
>>
>>
>>> garbage collection is a form of automatic resource management.
>>>
>>>
>>> Most GC experts would strongly disagree, if by resource you mean
>>> anything else but memory.
>>>
>>
>> Memory is most certainly a resource. Languages that are not GCd like C++
>> really don't make the distinction we make :)
>>
>> Garbage collection can and does in fact manage resources in JavaScript
>> host environments right now. For example, an XMLHttpRequest *may *abort
>> the underlying HTTP request if the XMLHttpObject is not referenced anywhere
>> and gets garbage collected.
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160217/6d382ba1/attachment-0001.html>