* Steve H's observation "this old bug was fixed", and my confession-of- bugfix-removal, were about Robert Parlett's example, not Art's original. Art's original example deserves further study.
* Icon does *not* leak memory for ordinary simple long-running coroutine pairs. You all know how amazingly scarce true bugs are in Icon :-) There is code in there that detects the common case of two coroutines calling each other back and forth, and avoids "infinite pushing" in that case. MT Icon routinely uses 3+ coroutines, such as target program and a monitor coordinator that forwards events to one or more execution monitors. In this scenario (or Icon programs using coroutines with similar patterns) the "bugfix" leaks memory and is therefore disabled when MultiThread is turned on (which is default in Unicon). The memory dredges such items up rather slowly sometimes. My thanks again to Steve Hunter for jogging my memory. It would still be useful to explore ways to generalize the bugfix or perhaps leave it in place when monitoring is not in use, but the leak is not specific to monitoring. Cheers, Clint [EMAIL PROTECTED] ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Unicon-group mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/unicon-group
