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