This is the mail archive of the
mailing list for the Cygwin project.
pthread problem with latest cygwin dll snapshot
- From: "Arash Partow" <arashp at hotmail dot com>
- To: cygwin at cygwin dot com
- Cc: tpfaff at gmx dot net
- Date: Tue, 28 Oct 2003 00:12:35 +0000
- Subject: pthread problem with latest cygwin dll snapshot
Greetings to Thomas and all others involved in cygwin pthreads
I've downloaded the snapshots of cygwin1.dll (cygwin1-20031025.dll.bz2 and
cygwin1-20031027.dll.bz2), I think the prior is the one where Thomas made
changes and in the latter Corinna made changes to semaphores which I don't
how that might effect pthreads. In both cases the stress test can run
successfully under certain circumstances (which for normal application
execution are not acceptable) in-one instance reaching 9million+ thread
creations, however if one tries to do other things like edit a text file or
play an mp3 or some other task, the Thread-Test will crash. In GDB the call
stack shows the last call before the crash was to the cygwin1.dll, also
sometimes if you try to restart the Thread-Test right after it has crashed,
the new instance crashes almost immediately only ever getting up to about
~5000 thread creations.
There is an application that I have found that continually makes the
Thread-Test crash, its called TaskInfo (http://www.iarsn.com/taskinfo.html),
its basically a taskmanager on steroids. I use this application mainly to
check for memory leaks of applications running over long periods of time.
This application has a facility called Free RAM, if I have Thread-Test
running and I run Free RAM of taskinfo, the Thread-Test will crash. However
no other application on my systems crash.
I've attempted running Thread-Test with the snapshot dlls on the following
OSs and system configurations:
1.) Win2k (SP4) - P4-2.4Ghz 1024RAM
2.) WinXP (SP4) - P4-2.4Ghz 1024RAM
3.) WinNT (SP6) - P3-1.4Ghz 768RAM
3.) Win98 (SE) - P3-1.0Ghz 512RAM
In all instances they will run fine if there are no other applications
running in the background, and only the basic windows applications are
loaded into memory, and of course no one actually uses the PC, if however
the PC begins running other tasks the Thread-Test goes to hell.
I think getting the cygwin's pthreads implementation stable is a very
important task because I know of many applications under *nixs that require
stable threading to perform their operations properly, and well it would be
nice to see some of those applications running on windows using the cygwin
So keep up the good work, at least now the test can get pass 250k thread
creations even though you can't really use the system, which is more than
what was happening before.
PS: Thanx to Ross Johnson's feed-back I've updated the Thread-Test's
garbage collector to work a bit more efficiently than it did before.
The source code can be downloaded from:
i can confirm that this is a bug in cygwin.
I will apply my changes when your testcase runs successfull over night,
therefore this should be fixed one of the next snapshots.
Thanks for your stress test.
Arash Partow wrote:
The prototype initially creates 700 threads all of which are contained in
vector (threadList), each thread does some "simple" string processing
(basically tokenize a string) and then exists. On completion of the
the thread sets its own state in the thread-class to dead.
Another thread called GarbageCollector, which is created before the other
threads are created, is continually traversing the threadList, looking for
dead threads, once a dead thread is found, it deletes the pointer pointing
to the thread class in the list, creates a new thread and adds it to the
end of the list. Hence continually maintaining the number of threads being
run at any one time, (hopefully)
Get less junk mail with ninemsn Premium. Click here
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html