Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <4fd08104e6065d20682122c1ee564453@rehley.net> References: <44f83c19cc33e4382680fe3758164ccf AT rehley DOT net> <20050527202823 DOT GB4939 AT trixie DOT casa DOT cgf DOT cx> <0833be552ca5aa00a72ecef822250580 AT rehley DOT net> <20050528161515 DOT GA1323 AT trixie DOT casa DOT cgf DOT cx> <1064750c32ec165a486fe7dba0f8b302 AT rehley DOT net> <429CA3E8 DOT 7070909 AT acm DOT org> <0483fbf499cd644361f2e16f2e88f7d5 AT rehley DOT net> <4fd08104e6065d20682122c1ee564453 AT rehley DOT net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: From: Peter Rehley Subject: Re: pthreads, cygwin and pthread_mutex_lock not blocking Date: Tue, 7 Jun 2005 10:22:11 -0700 To: "Cygwin List'" X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id j57HMQ6c007433 Any comments about this? On Jun 2, 2005, at 11:22 AM, Peter Rehley wrote: > Here is a patch to thread.cc that allows _lock to process signals. > The patch is against the 1.178 version of thread.cc found in cvs. > > --- thread.cc.orig Thu Jun 2 11:17:39 2005 > +++ thread.cc Thu Jun 2 11:20:00 2005 > @@ -1543,8 +1543,24 @@ > } > else > { > - WaitForSingleObject (win32_obj_id, INFINITE); > - set_owner (self); > + //WaitForSingleObject (win32_obj_id, INFINITE); > + //set_owner (self); > + bool loop = true; > + do > + switch (pthread::cancelable_wait (win32_obj_id, INFINITE, > false, true)) > + { > + case WAIT_OBJECT_0: > + set_owner (self); > + loop=false; > + break; > + case WAIT_SIGNALED: > + _my_tls.call_signal_handler (); > + break; > + default: > + // should never happen > + return EINVAL; > + } > + while (loop); > } > > return result; > > On Jun 1, 2005, at 6:17 PM, Peter Rehley wrote: > >> 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 >>>> ). 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/ >> >> >> > 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/