delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/07/22/13:12:08

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <13028667.1122052312636.JavaMail.dgou@mac.com>
Date: Fri, 22 Jul 2005 13:11:52 -0400
From: Doug Philips <dgou AT mac DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Known issues with Pthreads in 1.5.18?
in-reply-to: <4fc195f205072208471d60b4e0@mail.gmail.com>
Mime-Version: 1.0
references: <1122038226 DOT 24364 DOT ezmlm AT cygwin DOT com> <4fc195f205072208471d60b4e0 AT mail DOT gmail DOT com>
X-IsSubscribed: yes

>> From: "Dave Korn" <dave DOT korn AT artimi DOT com>
>> To: <cygwin AT cygwin DOT com>
>> Date: Fri, 22 Jul 2005 11:47:40 +0100
>> Subject: RE: Known issues with Pthreads in 1.5.18?
>>   The default type of mutex just got changed, from error checking, to
>> normal.  If your code is setting up a default mutex and then one thread
>> attempts to recursively take the mutex, it will now deadlock where before it
>> would have succeeded.  Or it may be possible your code is unlocking the
>> mutex more times than it takes it, which would probably show the same
>> symptom.  See the thread starting at:
>> 
>> http://www.cygwin.com/ml/cygwin/2005-05/msg01298.html
>> 
>> and the announcment for 1.5.18
>> 
>> http://www.cygwin.com/ml/cygwin-announce/2005-07/msg00001.html
>> 
>> in particular the line that says
>> 
>> "cgf: Change default value for PTHREAD_MUTEX_DEFAULT to PTHREAD_NORMAL."
>> 
>> 
>>     cheers,
>>       DaveK

Unfortunately that seems to have borked Python 2.4. I found that out the hard way after returning from a week offline, I just upgraded everything to 1.5.18 and as a result dequeuing operations stopped blocking and started getting "temp. unavailable" errors. No, I didn't bother saving the messages nor the configuration. Going back to older versions was a huge pain (at least when using setup.exe because an accidental/exploratory click could cause a newer version of a package to be selected which would prereq 1.5.18 again.. anyways)...
Since I don't have a second machine to infect with 1.5.18, I cannot directly re-produce this. My code used Python threads, one consumer, one producer. Instead of the consumer blocking, it would get an error trying to get a mutex, "resource temporarily unavailable." I have no idea if this is a bug in the python Queue code, python threading, or just an unexpected side-effect of changing mutex behaviour. Scanning the archives it didn't seem obvious that anyone else had seen this...

Since I'm not in a position to "fix this myself", I can offer to exchange toy python programs with someone who can, in an effort to track down where the bug is originating.

Thanks,
     --Doug


--
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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019