This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Problem with pthreads and signaling, behavior broken...

On Fri, Dec 12, 2003 at 02:43:03AM +0000, Arash Partow wrote:
>Hi Chris,
>Sorry about the late reply, now here is the best I can do with
>the debug 101 skills.
>The problem/issue/possible bug that "I" see when I run ThreadTest is the
>following, I run ThreadTest and let it reach about 2k threads completed.
>at that point i hit ctrl+c. I see that the main loop in the garbage
>collector is broken out of then the next loop which only deletes completed
>threads and does not renew them begins. At this point EVERYTHING slows
>down. using dll from 19th nov, you can see that about 2-3 seconds after
>you press ctrl+c the 2nd loop in the GC finishes off and the application
>closes gracefully. however in the latest dlls including 11th Dec. This
>is not the case.

>What happens once ctrl+c is press?
>Well its simple threads continue on running, obviously no new threads
>are being created cause the GC is in the final clean up loop. but what
>i do notice (through taskinfo) is that if i view the ThreadTest process in
>flat view mode giving me a view of all the child threads the application
>has created, there is "1" thread that is using 99% of the CPU,
>and no other processes including normal windows processes get any
>CPU time. Using cygwin1.dll from 19th Nov this behavior does not occur.

Wow.  How many times has it been that the above has been repeated now?
Having you, or anyone, repeatedly describe the symptoms with no new
information serves no purpose.

>I saw your code was doing something which made the threadtest work now
>with the new dll, I went through my original version of thread test and
>found that if i add the following lines to the inside of the cleapup loop
>(2nd loop) in the GC, it works with the current snapshot dlls.
>new 2nd loop:
>     int countloops = 0;  <----------- new line of code
>     /* clean up any remaining threads */
>     while(threadList.size() > 0)
>     {
>        vector <int> delPos;
>        for(unsigned int i=0; i < threadList.size(); i++)
>        {
>           if (threadList[i]->getThreadState() == THREAD_DEAD) 
>        }
>        /* Recalibrate deletion positions */
>        for (unsigned int i=1; i < delPos.size(); i++)
>        {
>           delPos[i]-=i;
>        }
>        for (unsigned int i=0; i < delPos.size(); i++)
>        {
>           /* Erase thread and free-up memory */
>           delete threadList[delPos[i]];
>           threadList.erase(threadList.begin()+delPos[i]);
>        }
>        delPos.clear();
>        if ((++countloops) % 1000 == 0) <-----------|
>        {                               <-----------|
>           usleep(10000);               <-----------| new lines of code
>        }                               <-----------|
>     }
>it seems that by putting in a delay in the loop, the problem is
>fixed, why is that ? and why isn't the problem seen with the snapshot
>from 19th Nov?

Thank you for the new information.  It isn't much, but I will ponder on
what could be causing this behavior.

If you have new information, please just provide it without starting
from zero.


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]