pthreads, cygwin and pthread_mutex_lock not blocking

[Peter Rehley]

Here is the patch to pthread.h

hummingbird:~/MontaVista/tmp prehley$ diff -u pthread.h.cygwin 
pthread.h.new
--- pthread.h.cygwin    Wed Jun  1 18:15:40 2005
+++ pthread.h.new       Wed Jun  1 18:06:49 2005
@@ -53,12 +53,12 @@
  #define PTHREAD_MUTEX_RECURSIVE 0
  #define PTHREAD_MUTEX_ERRORCHECK 1
  #define PTHREAD_MUTEX_NORMAL 2
-#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_ERRORCHECK
+#define PTHREAD_MUTEX_DEFAULT PTHREAD_MUTEX_NORMAL
  /* this should be too low to ever be a valid address */
  #define PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP (pthread_mutex_t)18
  #define PTHREAD_NORMAL_MUTEX_INITIALIZER_NP (pthread_mutex_t)19
  #define PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP (pthread_mutex_t)20
-#define PTHREAD_MUTEX_INITIALIZER 
PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP
+#define PTHREAD_MUTEX_INITIALIZER PTHREAD_NORMAL_MUTEX_INITIALIZER_NP
  #define PTHREAD_ONCE_INIT { PTHREAD_MUTEX_INITIALIZER, 0 }
  #define PTHREAD_PRIO_INHERIT
  #define PTHREAD_PRIO_NONE
@@ -202,4 +202,3 @@
  #endif

  #endif /* _PTHREAD_H */
-

On Jun 1, 2005, at 5:22 PM, Peter Rehley wrote:

>
>
> On May 31, 2005, at 10:50 AM, David Rothenberger wrote:
>
>> On 5/31/2005 10:15 AM, Peter Rehley wrote:
>>> Well, here is a simple test case, but turns out I wasn't using the 
>>> latest version.  I was having the problem on 1.5.12,  I haven't been 
>>> able to get a good build with cygwin 1.5.17-1.  It builds and I can 
>>> run the install script, but when I put the dll in place I see the 
>>> message "cygheap magic number mismatch detected", and gcc doesn't 
>>> want to work.
>>
>> I had a similar problem (see 
>> <http://cygwin.com/ml/cygwin/2005-05/msg01251.html>). It turned out 
>> it was because I was using the latest release of binutils. Try 
>> rolling back to the previous release.
>>
> Ok, I rolled binutils to 20041229, rebuilt and copied the new dll.  
> It's having the same issue that I see in 1.5.12.  When I debug the 
> program, I see that the signal is being sent, but it doesn't get 
> executed.
>
> I've looked at the cygwin code, and I have noticed that the sleep 
> (nanosleep) is calling pthread::cancelable_wait, and that will call 
> WaitForMultipleObjects.  However, in pthread_mutex::_lock, it's only 
> using WaitForSingleObject.  I'm wondering if something like 
> WaitForMultipleObjects should be added to the lock function so that 
> signals (SIGCHLD, in my case) can be handled.
>
> It's just a guess since I'm not an expert with this code.
>
> Enjoy,
> Peter
> -------------------------------
> A Møøse once bit my sister
>
>
> --
> 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/
>
>
>
Enjoy,
Peter
-------------------------------
A Møøse once bit my sister


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