On Jun 8, 2005, at 7:42 AM, Corinna Vinschen wrote:
On Jun 7 10:22, Peter Rehley wrote:
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
On Jun 7 10:22, Peter Rehley wrote:
> 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.
Thanks for the patch, but it's big e
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
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
Here is the patch to pthread.h
hummingbird:~/MontaVista/tmp prehley$ diff -u pthread.h.cygwin
pthread.h.new
--- pthread.h.cygwinWed 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
I'm coming to this particular party pretty late, so if my comments are
totally off-base or have been already covered, please disregard:
> 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
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
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 i
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 nu
On Fri, May 27, 2005 at 04:35:39PM -0700, Peter Rehley wrote:
>On May 27, 2005, at 1:28 PM, Christopher Faylor wrote:
>
>>On Fri, May 27, 2005 at 10:57:34AM -0700, Peter Rehley wrote:
>>>I'm trying to use pthread in cygwin, and I'm expecting the function
>>>pthread_mutex_lock to block when used. H
On May 27, 2005, at 1:28 PM, Christopher Faylor wrote:
On Fri, May 27, 2005 at 10:57:34AM -0700, Peter Rehley wrote:
I'm trying to use pthread in cygwin, and I'm expecting the function
pthread_mutex_lock to block when used. However it is returning error
45 (EDEADLK).I'm using a static ini
On Fri, May 27, 2005 at 10:57:34AM -0700, Peter Rehley wrote:
>I'm trying to use pthread in cygwin, and I'm expecting the function
>pthread_mutex_lock to block when used. However it is returning error
>45 (EDEADLK).I'm using a static initializer for the thread so the
>mutex is type PTHREAD_
try posting some explaining code
--
--
I use PGP/GPG. Ask for my key if interested.
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin
Hi,
I'm trying to use pthread in cygwin, and I'm expecting the function
pthread_mutex_lock to block when used. However it is returning error
45 (EDEADLK).I'm using a static initializer for the thread so the
mutex is type PTHREAD_MUTEX_DEFAULT.
When I look through the pthread code I see th
14 matches
Mail list logo
