In article <ekfev7$1d8l$1@[EMAIL PROTECTED]
>,
Gregg Townsend <gmt@[EMAIL PROTECTED]
> wrote:
>When a generator suspends, it can't assume it will ever be resumed.
>For the example you gave, I'd probably read fetch all the results
>into an array, close the database connection, and then generate the
>array contents. Of course, that assumes that the results can fit
>in memory reasonably.
I don't know if you recall, but I ran into a similar issue a few
years ago. I wanted to re-implement find using KMP, and I couldn't
find a place to free the extra data structure. This is about the
same problem here...
I don't know if unicon has any solution for that, but Icon definitely
lacks some `finally' mechanism, for lack of a better word. There are
ways to know a generator goes out of scope (without co-processes, one
just has to look at the enclosing expressions), and there are compelling
reasons to allow a generator to release stuff properly at some point.
As another example, assume I have a generator that yields lines of a file,
and that I want to lock the file for concurrent accesses. With the
current generator model, I simply can't, because there is no safe way
to ensure the file will be unlocked when the generator ends.
|
