Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; 	charset="us-ascii"
Subject: RE: Python 2.4.1 locking bug. (was: Re: rebaseall failure?)
Date: Thu, 28 Jul 2005 18:02:24 -0400
Message-ID: <94BF3137C62D3E4CAED7E97F876585F09DB07B@pauex2ku08.agere.com>
From: "Williams, Gerald S \(Jerry\)" <gsw AT agere DOT com>
To: "Jason Tishler" <jason AT tishler DOT net>, <cygwin AT cygwin DOT com>
Content-Transfer-Encoding: 8bit

Christopher Faylor wrote:
>>> semaphore::_trywait doesn't have anything to do with pthread
>>> mutexes, AFAIK.

Douglas Philips wrote:
>> The real issue is that Python broke with 1.5.18, either because of
>> the pthread change or not. Be that as it may, should I report this
>> bug in another forum? 

Jason Tishler wrote:
> No, this is the right mailing list.  However, you can increase the
> probability of it getting fixed by helping to isolate the problem.
> Besides submitting a patch, a minimal C test case is the best
> way to go.

Please ignore this if it sounds like noise, but I thought at
least Jason might be interested.

I wasn't following this thread closely since rebaseall had been
mentioned, but the semaphore/pthread/Python mix wakened an old
memory that I thought I should bring up. Give me a minute while
I crank up the old wayback machine... :-)

3 or 4 years ago I introduced a patch into Python thread support
that used native semaphores if they are supported. The POSIX way
to indicate this is to define _POSIX_SEMAPHORES in a header file,
but at the time either Cygwin either didn't define it, defined it
in some way differently, or its definition was ignored for some
reason (I don't remember the exact details).

It was frustrating to me since the reason for my change was to
fix Python threading under Cygwin, which was broken at the time,
and although the Python developers accepted my change, they
would only allow:
 #ifdef _POSIX_SEMAPHORES
and not:
 #if defined(_POSIX_SEMAPHORES) || defined(__CYGWIN__)

Fortunately, somebody else fixed the pthreads threading bug in
Cygwin (the lack of an assignment prevented me from doing so),
so things progressed without my help.

Anyway, I just looked into /usr/include/sys/features.h, and
_POSIX_SEMAPHORES is now defined. If we are seeing errors that
indict semaphore::_trywait, it seems likely that my code is
now being used, although I know that it wasn't being used when
I first introduced it into Python. However, features.h does
not appear to have changed in a while (at least not according
to its comments). :-P

Did something change (either in Cygwin or Python) that could
explain why Python would have started recognizing that Cygwin
supports POSIX semaphores? If so, perhaps that is contributing
to the error. I'd poke around myself, but it's been a while
since I've been inside either Python or Cygwin internals.

On the other hand, I verified at the time that the semaphore
solution worked under Cygwin Python, so I wouldn't expect it
to be a problem even if the change just took place. However,
it could potentially help in isolating the problem.

-Jerry


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/