Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <006001c0c4af$179b79c0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Jason Tishler" <Jason DOT Tishler AT dothill DOT com>
Cc: <cygwin AT cygwin DOT com>
References: <037701c0c3ab$9049bf30$0200a8c0 AT lifelesswks> <20010413221222 DOT C5606 AT dothill DOT com>
Subject: fork expert needed: (was Re: pthreads update for the adventurous)
Date: Sat, 14 Apr 2001 16:49:43 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 14 Apr 2001 06:42:56.0694 (UTC) FILETIME=[2398BD60:01C0C4AE]

----- Original Message -----
From: "Jason Tishler" <Jason DOT Tishler AT dothill DOT com>
To: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
Cc: <cygwin AT cygwin DOT 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 DOT Tishler AT dothill DOT com
> Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple