> If there were a way to query Unicon for the number of
> threads/co-expressions, that might be useful.
> I could run that in a separate thread and watch the growth. (The same
> thread could monitor string/heap/etc
> memory consumption.)
>
Querying the number of live threads is a fine idea, add to that ways to
query specific thread state like how much memory is used by the thread or
how many garbage collection done by the thread. We thought about extending
several keywords to do such things. We may see such extensions in near
future releases.
> Thanks for checking this!! I'll report back in a month or so after
> upgrading to CentOS 6...
>
> [I *think*, without doing a lot of it, that ar uses approximately 2^N
> threads, where N is the argument.
> so ar 10 uses ~1024 threads, ar 12 is at 4096, and ar 14 (laptop still
> runs) 16384.]
>
> 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.
> This wouldn't explain why my laptop beats my big machine, but might help
> explain why things
> don't run longer in general.
>
> Is there any way to check this?
>
The answer to this is mixed, after a quick look at the code to refresh my
memory and a quick test I have these comments:
I will use the term co-exp to refer to the conventional non-concurrent
co-expression and the term thread to refer to concurrent co-expression.
While threads are identical to co-expression in almost every aspect, and we
think of threads as a special case of co-expression, The assumption is they
will be used in different ways and take separate non-crossing paths during
execution. In other words, once a co-expression gets created, it will either
gets activated -that makes it a co-exp- or fired by passing it to the thread
function -that makes it a thread-. You can't change between the two, at
least under the current implementation, if you do so the behavior is
undefined and might be catastrophic! this will likely change in the future
as we find ways to melt the two together.
Why is that relevant? because co-exp can be activated/suspended as many
times I you wish. consider the following
co-exp A activates B
co-exp B activates A
After this, B is still live. You can't free its resources. Even though as a
programmer you might know that B will never be activated again. and worse..
If B "return" or "fail" and we know it is done. We still can't claim its
resources, because few lines below the programmer might refresh it (^B). We
could free and then reallocate every time this happens, but that will be
very very inefficient. Instead of investing the time to address these issues
in pthread-based co-exp, we thought, supporting native co-expressions for
co-exp use will fix many of these issues for free. BTW, threads do free
their resources, otherwise, things like join()/wait() would never work. It
is only co-exps that are "lazy".
Now, you still have a valid argument Steve, if a co-exp is complete and it
is "unreachable" then it still could be garbage collected. and that what
actually happens, BUT, the pthread-thread associated with it doesn't get
released until the program ends. That is something we might be able to
improve.
One last thing is memory, co-exps/threads always start with fresh allocated
heaps. The program keeps track of all heaps, in some cases it might be
possible to "recycle" some heaps for reuse without allocating new ones. This
is another thing we can improve on.
Thanks for all of your tests/comments/thoughts. We will gradually see these
improvements/features in the coming weeks/months.
Cheers,
Jafar
> --
> Steve Wampler -- [email protected]
> The gods that smiled on your birth are now laughing out loud.
>
--
"Let there be no compulsion in religion: Truth stands out clear from error"
[The Holy Qur'an 2:256]
"Injustice anywhere is a threat to justice everywhere" Dr. King
------------------------------------------------------------------------------
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
