This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
fork expert needed: (was Re: pthreads update for the adventurous)
----- Original Message -----
From: "Jason Tishler" <Jason.Tishler@dothill.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: <cygwin@cygwin.com>
Sent: Saturday, April 14, 2001 12:12 PM
Subject: Re: pthreads update for the adventurous
> Rob,
>
> On Fri, Apr 13, 2001 at 09:51:57AM +1000, Robert Collins wrote:
> > This is a plea for testing. On this list we've seen discussions
about
> > pthreads for
> > g++,
> > gcj,
> > miniORB,
> > python
> > and who knows what else in the past.
>
> The following is an update to my previous report regarding Python
built
> with thread support.
>
> On Tue, Mar 27, 2001 at 09:27:03AM -0500, Jason Tishler wrote:
> > I had the following issues when I configured Python to use your
pthreads
> > support:
> >
> > 1. To compile I had to apply the attached patch to sys/signal.h.
IIRC,
> > this is a known issue.
>
> This issue is resolved. Python builds OOTB when thread support is
enabled
> (which is the default).
Excellent.
> > 2. The Python regression tests run much slower with pthreads enabled
> > than without. Also, the CPU seemed to be pegged at 100% more often
> > with pthreads than without.
>
> The above is still unfortunately true -- the regression tests took
> almost 5 hours to complete!
Can you profile your python for one of the tests that peg the cpu at
100%, and see what function(s) are getting most cpu time? None of the
pthreads functions poll, so it's either (a) bad programming in python
(unlikely, or it'd have been noticed on unix :]) or b) a confusing
response from the pthreads calls breaking python.
> > 3. The Python regression tests consistently crash during test_popen2
> > with the following error message:
> >
> > H:\src\Python-2.1b2a-threads\python.exe: *** couldn't release
memory 0x1A02C000(5013504) for
'H:\src\Python-2.1b2a-threads\build\lib.cygwin_nt-4.0-1.3.0-i686-2.1\ima
geop.dll' alignment, Win32 error 487
> >
> > 358288600 [main] python 366 sync_with_child: child 269(0x248)
died before initialization with status code 0x1
> > 358288838 [main] python 366 sync_with_child: *** child state
child loading dlls
> > 358291613 [sig] python 366 stackdump: Dumping stack trace to
python.exe.stackdump
> The test_popen2, test_select, and test_socket tests all crash with the
> following error message:
>
> H:\src\Python-2.1b2a-threads\python.exe: *** couldn't release memory
0x1A02C000(5058560) for
'H:\src\Python-2.1b2a-threads\build\lib.cygwin_nt-4.0-1.3.0-i686-2.1\gdb
m.dll' alignment, Win32 error 487
>
> 0 [main] python 110 sync_with_child: child 272(0x244) died
before initialization with status code 0x1
> 288 [main] python 110 sync_with_child: *** child state child
loading dlls
> test test_popen2 crashed -- exceptions.OSError: [Errno 11] Resource
temporarily unavailable
Hmm, sync_with_child is not tied to pthreads code in any particular way.
To me this is threading uncovering another bug in cygwin somewhere else.
(Possibly a race in fork?).
Could the parent be loading any dll's or libraries at the same time as
the fork() call? what other threads are active at the time of the fork()
(Simple code inspection should do).
Unfortunately I'm out of my depth at the point - although I'll muddle
through the cygwin code and see if I can make any suggestions for
simpler test cases.
> Well, at least Python is no longer stackdumping.
One step at a time :]
> Jason
>
> --
> Jason Tishler
> Director, Software Engineering Phone: +1 (732) 264-8770 x235
> Dot Hill Systems Corp. Fax: +1 (732) 264-8798
> 82 Bethany Road, Suite 7 Email: Jason.Tishler@dothill.com
> Hazlet, NJ 07730 USA WWW: http://www.dothill.com
>
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple