On 07/26/2011 02:14 PM, Steve Wampler wrote: > Come to think of it, there ought be to be some co-expressions completing and > so finishing with their > threads as the program runs. At most N threads should be 'active' at any one > time since these > are plain-old non-concurrent co-expressions. This makes me think that the > co-expressions aren't > being freed when they complete [and not garbage collected, either] and so the > threads aren't released.
As a follow-up, I turned off Concurrent in config.h to get back to basic co-expressions and things run much better. I ran ar 22 with no problems (unwilling to sit through higher N). I don't know if that tells us very much, other than verifying the fact that threads are expensive. I suspect (wild guess here) that the GC isn't collecting the 'dead' co-expressions because of some hidden references chaining the co-expression blocks together. With plain co-expressions that's not so bad, but when there's one thread/co-expression it becomes apparent much faster. Short of instrumenting the runtime code to report when co-expressions are actually being freed, I don't know of a way to test this suspicion. -- Steve Wampler -- [email protected] The gods that smiled on your birth are now laughing out loud. ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ Unicon-group mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/unicon-group
