Steve,
Here is a follow up on this. I happened to be running Windows 7 Ultimate
32-bit at the moment, and because it is always fun to test under Windows, I
went a head and ran you little program. Here are the results:-
c:\projetcs>ar 1
fib(1)=1
c:\projetcs>ar 2
fib(2)=1
c:\projetcs>ar 3
fib(3)=2
c:\projetcs>ar 4
fib(4)=3
c:\projetcs>ar 5
fib(5)=5
c:\projetcs>ar 6
fib(6)=8
c:\projetcs>ar 7
fib(7)=13
c:\projetcs>ar 8
fib(8)=21
c:\projetcs>ar 9
fib(9)=34
c:\projetcs>ar 10
fib(10)=55
c:\projetcs>ar 11
System error at line 24 in ar.icn
cannot create thread
You can see that all went well up to fib(10). At 11, my system runs out of
resources quickly because the number of (co-exp) threads involved seems to
be more than what the system can handle in its current state (I'm
multi-tasking.. and firefox is running with 10s of tabs :) open ). To get a
better handle on this, I tried the little toy "unicon\tests\thread\sum.icn"
because I can control (and know) how many threads are running. With Windows
task manager open, I ran "sum" several times with different arguments. The
argument is the number of threads to be created. I was able to run "sum"
with up to 225 threads. Adding one more thread was enough to get Windows
"fed up" with my test and start throwing several error messages, including
the one above and also the ones you reported earlier which are actually
symptoms of the above error. I can see in Windows Task Manager that the
number of threads jumps roughly by how many threads "sum" creates. The total
number of threads in the system seems to gap between 900 and 1000.
Insufficient memory, uninitialized mutexes, threads are all parts of the
error messages I get.
There is nothing we can do about the number of threads a system can handle.
But maybe we can, at least do so for "conventional" non-concurrent co-exp.
At the moment, in concurrent unicon all co-expressions are pthread-based,
they are not cheap, whether they are concurrent or not. They usually map to
kernel threads. Conventional co-exp are unicon- or application-level "kind
of" threads. You can create thousands of them, the system doesn't care, it
doesn't know about them anyway. We hope one day, Unicon can support both,
light-weight non-concurrent conventional co-expressions, and heavy-weight
concurrent-capable co-expressions. Human-Money resources will determine how
soon or late that day will be. :)
I will add that we can still do something about the above error. We need to
handle it better. Not sure if changing it to failure makes sense where the
program can decide what to do. But at least until now, the thread that
issues the system error, doesn't care about other running threads sending
them to chaos! that is why you see different errors with SIG fault
sometimes. That is something we can fix... hopefully easily!
So, yeah, at the end, this is a legitimate bug report! :)
Cheers,
Jafar
On Tue, Jul 26, 2011 at 10:53 AM, Jafar Al-Gharaibeh <[email protected]>wrote:
>
> On Tue, Jul 26, 2011 at 9:35 AM, Steve Wampler <[email protected]> wrote:
>
>> On 07/25/2011 12:43 PM, Jafar Al-Gharaibeh wrote:
>> > Steve,
>> >
>> > I was able to reproduce the problem you were seeing on my CentOS
>> 2.6. It appears every 20 runs or so on my side.
>> > Running the program under gdb didn't get me any where as I get really
>> weird behavior. When running under gdb I get wrong
>> > results, fib(12) gives 12 instead of 144 after creating two threads or
>> so and I wasn't able to make the problem appear.
>> > I can't trust gdb in this case. Under Fedora 12, not only the problem
>> doesn't reproduce for me, but also, under gdb I
>> > get correct results with hundreds of threads created. Not sure where/how
>> to proceed form here. :-)
>> >
>> > At this point, I can say the problem is CentOS specific unless someone
>> can make it appear on another platform.
>>
>> (When you say CentOS 2.6, you mean CentOS 5.6, correct?)
>>
>
> I think so. I believe there kernel is 2.6.18. It was the latest CentOs when
> I installed it earlier this year.
>
>
>
>>
>> Thanks! I'll try this again when I upgrade to CentOS 6.x (soon, he
>> hopes).
>>
>> -Steve
>> --
>> Steve Wampler -- [email protected]
>> The gods that smiled on your birth are now laughing out loud.
>>
>>
>> ------------------------------------------------------------------------------
>> Magic Quadrant for Content-Aware Data Loss Prevention
>> Research study explores the data loss prevention market. Includes in-depth
>> analysis on the changes within the DLP market, and the criteria used to
>> evaluate the strengths and weaknesses of these DLP solutions.
>> http://www.accelacomm.com/jaw/sfnl/114/51385063/
>> _______________________________________________
>> Unicon-group mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/unicon-group
>>
>
>
>
> --
> "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
>
--
"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
