info, Yaakov. Accoring to the manual -std determines the
> language standard and c11 means ISO C11, the 2011 revision of the ISO C
> standard. Howevery, I find no restriction on POSIX in ISO/IEC 9899:2011. So
> why should -std=c11 have an influence on Pthreads? Am I missing something?
ISO/I
t;> Yaakov
>>
>> --
>
> Many thanks for the info, Yaakov. Accoring to the manual -std determines the
> language standard and c11 means ISO C11, the 2011 revision of the ISO C
> standard. Howevery, I find no restriction on POSIX in ISO/IEC 9899:2011. So
> why shoul
s the
language standard and c11 means ISO C11, the 2011 revision of the ISO C
standard. Howevery, I find no restriction on POSIX in ISO/IEC 9899:2011. So why
should -std=c11 have an influence on Pthreads? Am I missing something?
--
Problem reports: http://cygwin.com/problems.html
FAQ:
On 2017-07-12 11:15, bz0...@tirol.com wrote:
> gcc does not recognize some functions from pthread.h if option -std=c11 is
> used:
Exactly, and the same happens with glibc. When you use -std=c*, that
means you are declaring strict ISO C, and all extensions are disabled by
default unless explicitl
Hello,
gcc does not recognize some functions from pthread.h if option -std=c11 is used:
#include
#define THREADS 5
int main (int argc, char *argv[])
{
pthread_barrier_t barrier;
pthread_barrier_init(&barrier, NULL, THREADS);
}
gcc -std=c11 -o test test.c
test.c: In function ‘main’:
test.c:
On Jul 30 06:37, JonY wrote:
> Hi,
>
> After removing 4.8-cmodel-medium.patch and 4.8-duplicate-symbols.patch
> for 32bit cygwin, 2nd stage libgcc fails with spawn error, "C compiler
> cannot create executables".
I thought the 4.8-cmodel-medium.patch only affects the x86_64 target.
> Running the
Hi,
After removing 4.8-cmodel-medium.patch and 4.8-duplicate-symbols.patch
for 32bit cygwin, 2nd stage libgcc fails with spawn error, "C compiler
cannot create executables".
Running the compile command manually does show it running cc1, but hangs
indefinitely, adding -v causes it to emit xgcc: er
On 7/26/2013 17:45, JonY wrote:
> On 7/26/2013 13:02, Yaakov (Cygwin/X) wrote:
>> On 2013-07-12 05:33, JonY wrote:
>>> For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
>>> now default, for better MSVC compatibility. This may cause ABI changes
>>> in libraries that expose data
On 7/26/2013 13:02, Yaakov (Cygwin/X) wrote:
> On 2013-07-12 05:33, JonY wrote:
>> For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
>> now default, for better MSVC compatibility. This may cause ABI changes
>> in libraries that expose data structures directly to clients. Worka
On 2013-07-12 05:33, JonY wrote:
For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
now default, for better MSVC compatibility. This may cause ABI changes
in libraries that expose data structures directly to clients. Workaround
include marking the struct with the gcc_struct a
The mingw-pthreads package provides Pthreads-W32, for use with the
MinGW cross toolchain. Pthreads-W32 provides a POSIX-compliant pthreads
implementation for the Win32 platform. The MinGW cross toolchain's
libgomp library, which provides openmp support for that compiler, is
linked ag
This update includes:
Update:
mingw64-*-headers-3.0b_svn5935-1
mingw64-*-runtime-3.0b_svn5935-1
mingw64-*-gcc-4.7.3-1
mingw64-*-pthreads-20100619-5
New:
mingw64-*-winpthreads-3.0b_svn5935-1
*** NOTES ***
For gcc-4.7.x, struct alignment behavior has changed, -mms-bitfields is
now default, for
On Wed, May 08, 2013 at 04:47:46PM -0400, Ryan Johnson wrote:
>On 08/05/2013 2:36 PM, Christopher Faylor wrote:
>> On Tue, May 07, 2013 at 04:22:23PM -0400, Ryan Johnson wrote:
>>> Hi all,
>>>
>>> Running the attached STC inside gdb hangs (zero CPU util, have to kill
>>> gdb from Task Manager, kill
On 08/05/2013 2:36 PM, Christopher Faylor wrote:
On Tue, May 07, 2013 at 04:22:23PM -0400, Ryan Johnson wrote:
Hi all,
Running the attached STC inside gdb hangs (zero CPU util, have to kill
gdb from Task Manager, killing a.exe doesn't cut it).
Compile line used: g++ -Wall -g -mthreads -DBUG bu
On Tue, May 07, 2013 at 04:22:23PM -0400, Ryan Johnson wrote:
>Hi all,
>
>Running the attached STC inside gdb hangs (zero CPU util, have to kill
>gdb from Task Manager, killing a.exe doesn't cut it).
>
>Compile line used: g++ -Wall -g -mthreads -DBUG bug.cpp
>
>I currently have the following packa
Hi all,
Running the attached STC inside gdb hangs (zero CPU util, have to kill
gdb from Task Manager, killing a.exe doesn't cut it).
Compile line used: g++ -Wall -g -mthreads -DBUG bug.cpp
I currently have the following package versions:
cygwin-1.7.18(0.263/5/3) 2013-04-19
mintty-1.1.3-1
gdb-
produce a message but I can't tell what that
message is or why it's producing it. It could be that some Cygwin table
has reached its limit.
Does the backtrace make any sense to any Cygwin pthreads experts out there?
The crash can be reproduced in the full application only, see curre
mingw64-x86_64-pthreads-20100619-4 has been uploaded.
mingw64-x86_64-pthreads is a libpthread implementation for MinGW-w64
Win64 toolchain.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubs
mingw64-i686-pthreads-20100619-4 has been uploaded.
mingw64-i686-pthreads is a libpthread implementation for MinGW-w64 Win32
toolchain.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at the "List-Unsubscribe:
re.
>>
>> I have a 2 thread program. I set the break for main() and run (to main):
>>
>> (gdb) b main
>> Breakpoint 1 at 0x401191
>> (gdb) r
>> Starting program: /home/John/projects/pthreads/test1/a.exe
>> [New thread 3680.0x
breakpoints which
>> are only hit in a thread. So, yes, gdb is supposed to be multi-thread
>> aware.
>
> I have a 2 thread program. I set the break for main() and run (to main):
>
> (gdb) b main
> Breakpoint 1 at 0x401191
> (gdb) r
> Starting
(gdb) r
Starting program: /home/John/projects/pthreads/test1/a.exe
[New thread 3680.0x13e8]
Error: dll starting at 0x76ff not found.
Error: dll starting at 0x7659 not found.
Error: dll starting at 0x76ff not found.
Error: dll starting at 0x76c4
On Tue, Jul 12, 2011 at 06:16:14AM -0400, Jan Chludzinski wrote:
>I went to GNU.org to read about GDB and threads since I'm having
>trouble working with ptheads under GDB on Cygwin. I notice this on
>the GNU.org web site:
>
>"Warning: These facilities are not yet available on every GDB
>configurat
I went to GNU.org to read about GDB and threads since I'm having
trouble working with ptheads under GDB on Cygwin. I notice this on
the GNU.org web site:
"Warning: These facilities are not yet available on every GDB
configuration where the operating system supports threads. If your GDB
does not s
The mingw-pthreads package provides Pthreads-W32, for use with the
MinGW cross toolchain. Pthreads-W32 provides a POSIX-compliant pthreads
implementation for the Win32 platform. The MinGW cross toolchain's
libgomp library, which provides openmp support for that compiler, is
linked ag
mingw64-x86_64-pthreads-20100619-2 has been uploaded.
mingw64-x86_64-pthreads is a libpthread implementation for MinGW-w64
Win64 toolchain.
mingw64-x86_64-pthreads has been rebuilt with the new updated
mingw64-x86_64 toolchain.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want
mingw64-i686-pthreads-20100619-2 has been uploaded.
mingw64-i686-pthreads is a libpthread implementation for MinGW-w64 Win32
toolchain.
mingw64-i686-pthreads has been rebuilt with the new updated mingw64-i686
toolchain.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to
Version 20100619-1 of "mingw64-i686-pthreads" has been uploaded.
mingw64-i686-pthreads provides 32bit pthreads support. It is used by GCC
for OpenMP.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, look
at
Version 20100619-1 of "mingw64-x86_64-pthreads" has been uploaded.
mingw64-x86_64-pthreads provides 64bit pthreads support. It is used by
GCC for OpenMP.
*** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***
If you want to unsubscribe from the cygwin-announce mailing list, lo
On Mon, Dec 07, 2009 at 04:46:00PM +0100, Karsten Otto wrote:
>Hi everybody!
>
>I have a question regarding the delivery of signals to pthreads in
>Cygwin (1.7 beta). As an example, please consider the following
>situation (see attached file for source code):
>
>There ar
On Mon, Dec 07, 2009 at 04:46:00PM +0100, Karsten Otto wrote:
>Hi everybody!
>
>I have a question regarding the delivery of signals to pthreads in
>Cygwin (1.7 beta). As an example, please consider the following
>situation (see attached file for source code):
>
>There ar
Hi everybody!
I have a question regarding the delivery of signals to pthreads in
Cygwin (1.7 beta). As an example, please consider the following
situation (see attached file for source code):
There are two threads, a main thread and another one created by the main
thread.
The main registers
Dave Korn wrote:
And with gcc3 as well; and neither compiler can make it work on 1.5. So
it's a bug that was fixed sometime after 1.5 and before 1.7.
Thanks, I'll see if I can work out how to upgrade.
Cheers,
Nicholas Sherlock
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-si
Marco Atzeri wrote:
on
$ uname -a
CYGWIN_NT-5.1 ITQMOZCAS2NB007 1.7.0(0.200/5/3) 2009-02-20 17:20 i686 Cygwin
compiled with gcc-4
$ ./pthread.exe
Err 0
That might be making the difference, my uname -a output is:
CYGWIN_NT-6.0-WOW64 nick 1.5.25(0.156/4/2) 2008-06-12 19:34 i686 Cygwin
Marco Atzeri wrote:
> --- Mer 4/3/09, Nicholas Sherlock ha scritto:
>> This C program:
>> Should run correctly. That is, the second call to
>> pthread_rwlock_rdlock should either succeed (returning
>> zero), having acquired the read lock a second time, or it
>> should fail and return EAGAIN, if
--- Mer 4/3/09, Nicholas Sherlock ha scritto:
> Da: Nicholas Sherlock
> Oggetto: Cygwin PThreads bug?
> A: cygwin@cygwin.com
> Data: Mercoledì 4 marzo 2009, 02:29
> Hey everyone,
>
> I'm writing a very thread-intensive application using
> Cygwin and Cygwin'
Hey everyone,
I'm writing a very thread-intensive application using Cygwin and
Cygwin's PThreads implementation, and I'm running into a few problems.
As far as I can tell from the spec:
http://www.opengroup.org/onlinepubs/95399/functions/pthread_rwlock_rdlock.html
On Oct 1 13:44, Gabriel Landau wrote:
> Forgot attachments. Here they are, sorry.
>
> - Gabriel Landau
>
> Gabriel Landau wrote:
>> Hello,
>> I'm trying to develop a program that uses pthreads and needs to
>> recursively acquire RO rwlocks and RW rwlock
Forgot attachments. Here they are, sorry.
- Gabriel Landau
Gabriel Landau wrote:
Hello,
I'm trying to develop a program that uses pthreads and needs to
recursively acquire RO rwlocks and RW rwlocks. I'm not upgrading or
trying to acquire an RO lock after an RW lock has been acq
Hello,
I'm trying to develop a program that uses pthreads and needs to
recursively acquire RO rwlocks and RW rwlocks. I'm not upgrading or
trying to acquire an RO lock after an RW lock has been acquired, yet
pthread_rwlock_rdlock() keeps returning EDEADLK. I have tested the
att
Hi,
jdeifik wrote:
At 07:00 PM 3/21/2006, you wrote:
jdeifik wrote:
I have a dual xeon 2.4ghz machine with hypertreading enabled.
This gives me 4 logical processors.
I am not sure why it is important to have a HT aware scheduler for
Windows, when there are 4 or more
threads. I can see with
using cygwin pthreads and gcc-3.4.4
1434.60user 0.20system 7:16.47elapsed 99%CPU (0avgtext+0avgdata
509696maxresident)k
2441.78user 0.24system 3:42.06elapsed 199%CPU
(0avgtext+0avgdata 510208maxresident)k
3579.68user 0.15system 3:14.50elapsed 298%CPU
(0avgtext+0avgdata
efficiency, take the single thread elapsed time/(# threads *
threaded elapsed time)
There is virtually perfect scaling. 4 processors scale with an
efficiency of about 103%.
For 6 and 8 threads, efficiency goes up a small amount.
Here is the performance on windows xp using cygwin pthreads and gcc
elapsed time/(# threads
* threaded elapsed time)
There is virtually perfect scaling. 4 processors scale with an
efficiency of about 103%.
For 6 and 8 threads, efficiency goes up a small amount.
Here is the performance on windows xp using cygwin pthreads and gcc-3.4.4
1 434.60user 0.20system 7
diagnose (or learn to diagnose) this problem so
> > that I may create a more useful report?
> >
> > (Although a developer, I admit to being mostly ignorant of
> > make/configure issues...but I can learn.)
>
> Look in the build directory for the file config.log, searc
On Thu, 29 Sep 2005, Herb Martin wrote:
> I am attempting to ./configure 'dspam' for make
> on CygWin 1.5.18 (release with most all updates).
>
> ./configure --version
> dspam configure 3.6.rc3
> generated by GNU Autoconf 2.59
>
> ./configure gives t
I am attempting to ./configure 'dspam' for make
on CygWin 1.5.18 (release with most all updates).
./configure --version
dspam configure 3.6.rc3
generated by GNU Autoconf 2.59
./configure gives this pthreads related error message:
checking how you like your pthreads... unknown
Doug,
On Fri, Jul 22, 2005 at 01:11:52PM -0400, Doug Philips wrote:
> >> From: "Dave Korn"
> >> in particular the line that says
> >>
> >> "cgf: Change default value for PTHREAD_MUTEX_DEFAULT to
> >> PTHREAD_NORMAL."
>
> Unfortunately that seems to have borked Python 2.4. I found that out
> the
>> From: "Dave Korn" <[EMAIL PROTECTED]>
>> To:
>> 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 co
Original Message
>From: Fred Smith
>Sent: 22 July 2005 01:03
> I can't determine yet if I've got a subtle bug (quite possible) or if
> there's something whacko in cygwin. I'm hoping some of you can
> enlighten me as to the state of cygwin's pt
Hi gang!
I've been off the list for a few months, just got back on this week.
I recall seeing occasional notes about ongoing problems with pthreads
way back last winter before I got dropped off the list.
Well, I'm checking to see if a multi-threaded program I maintain at
work works on
Arash Partow wrote:
> What kernel version and what NPTL version do you have installed?
Kernel version 2.6.10 and glibc 2.3.2 as packaged by Debian unstable. I
don't know whether they configure glibc for LinuxThreads or NPTL for
this package.
Under FreeBSD-5.4 I get the following:
$ ./example1
Hi Brian,
What kernel version and what NPTL version do you have installed?
Kind regards
Arash Partow
__
Be one who knows what they don't know,
Instead of being one who knows not what they don't know,
Thinking they know everything about all thi
Arash Partow wrote:
> I've done a clean install of cygwin with dll 1.5.18 and also tried
> snapshots from 2nd, 4th and 5th. Unfortunetly issues relating to
> threading and memory leaks as described in the following post - still
> exists:
>
> http://sources.redhat.com/ml/cygwin/2005-06/msg00186.ht
On Wed, Jul 06, 2005 at 04:17:34AM +, Arash Partow wrote:
>I have the mutex set to default mode, and after a few seconds of the
>test running mutexes locking unlocking, all of a sudden the mutexes
>stop locking, and basically report back EBUSY from pthread_mutex_lock.
The message that you are
Hi Chris,
Actually things are getting slightly worse, basically same test scenario
(not the full blown app you keep on mentioning), but this time mutex
locks are failing + the ye-olde massive memory leaks.
I have the mutex set to default mode, and after a few seconds of the
test running mutexes
On Wed, Jul 06, 2005 at 01:36:54AM +, Arash Partow wrote:
>I've done a clean install of cygwin with dll 1.5.18 and also tried
>snapshots from 2nd, 4th and 5th. Unfortunetly issues relating to
>threading and memory leaks as described in the following post - still
>exists:
>
>http://sources.redh
Hi Chris,
I've done a clean install of cygwin with dll 1.5.18 and also tried
snapshots from 2nd, 4th and 5th. Unfortunetly issues relating to
threading and memory leaks as described in the following post - still
exists:
http://sources.redhat.com/ml/cygwin/2005-06/msg00186.html
Regards
Ar
Yeah, I tried the June 30th snapshot.
On Jul 1, 2005, at 1:21 PM, Christopher Faylor wrote:
On Fri, Jul 01, 2005 at 01:09:21PM -0700, Peter Rehley wrote:
My tests indicated that the changes are working correctly.
You did try the snapshot, right? I neglected to mention that I had to
make some
On Fri, Jul 01, 2005 at 04:21:20PM -0400, Christopher Faylor wrote:
>On Fri, Jul 01, 2005 at 01:09:21PM -0700, Peter Rehley wrote:
>>My tests indicated that the changes are working correctly.
>
>You did try the snapshot, right? I neglected to mention that I had to
>make some corresponding changes
On Fri, Jul 01, 2005 at 01:09:21PM -0700, Peter Rehley wrote:
>My tests indicated that the changes are working correctly.
You did try the snapshot, right? I neglected to mention that I had to
make some corresponding changes to the DLL beyond the below changes.
I don't know exactly when I did that
My tests indicated that the changes are working correctly.
Peter
On Jun 30, 2005, at 8:23 PM, Christopher Faylor wrote:
We're coming close to a 1.5.18 release. Please try the latest snapshot
at http://cygwin.com/snapshots/ and help verify that there are no
regresions against 1.5.17.
I'm part
We're coming close to a 1.5.18 release. Please try the latest snapshot
at http://cygwin.com/snapshots/ and help verify that there are no
regresions against 1.5.17.
I'm particularly interested in hearing if the changes made (at users's
requests) to the default mutex handling in pthread.h are worki
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
and it doesn't
seem at all similiar to "example1".
The example1 code itself is not but the support coding, the pthreads
wrapper is the same code.
>OK in simple terms this is what I see: I run example1 and open up my
>taskmanager and taskinfo and slowly watch the amount o
On Mon, Jun 06, 2005 at 02:28:45AM +, Arash Partow wrote:
>Hi Chris,
>
>How many times can we do this dance ? he he he he :)
>
>The code given is as simple as its gonna get. This is the same
>code used by Thomas Pfaff and by YOU to fix previous memory
>leaks found in cygwin :)
You may be right
Mon, Jun 06, 2005 at 12:37:14AM +, Arash Partow wrote:
>I'm encountering some memory leaks when using pthreads under cygwin.
>As usual the code has been compiled/run on other *nixes (openbsd3.7,
>netbsd2.0 and mandrake10.1) and the leak does not seem to occur.
>
>The system s
On Mon, Jun 06, 2005 at 12:37:14AM +, Arash Partow wrote:
>I'm encountering some memory leaks when using pthreads under cygwin.
>As usual the code has been compiled/run on other *nixes (openbsd3.7,
>netbsd2.0 and mandrake10.1) and the leak does not seem to occur.
>
>The
Hi all,
I'm encountering some memory leaks when using pthreads under cygwin.
As usual the code has been compiled/run on other *nixes (openbsd3.7,
netbsd2.0 and mandrake10.1) and the leak does not seem to occur.
The system specs are as follows:
1.) gcc 3.3.3
2.) cygwin dll, snapshots
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
Mark Pizzolato schrieb:
Reini Urban wrote:
Mark Pizzolato schrieb:
> I've been using clamav's clamd under cygwin and noticed that over time
> the handle count as viewed with TaskManager seems to grow to arbitrary
> values. I used clamd's option IdleTimeout set to 600 seconds which
> dramatically re
On Saturday, January 29, 2005 at 12:36 PM, Christopher Faylor wrote:
On Fri, Jan 28, 2005 at 09:09:31AM -0800, Mark Pizzolato wrote:
>I've been using clamav's clamd under cygwin and noticed that over time
>the
>handle count as viewed with TaskManager seems to grow to arbitrary
>values.
This shou
On Fri, Jan 28, 2005 at 09:09:31AM -0800, Mark Pizzolato wrote:
>I've been using clamav's clamd under cygwin and noticed that over time the
>handle count as viewed with TaskManager seems to grow to arbitrary values.
This should be fixed in the latest snapshot. Corinna tracked this down to
the o
Hi Reini,
Reini Urban wrote:
Mark Pizzolato schrieb:
> I've been using clamav's clamd under cygwin and noticed that over time
> the handle count as viewed with TaskManager seems to grow to arbitrary
> values. I used clamd's option IdleTimeout set to 600 seconds which
> dramatically reduced the grow
Mark Pizzolato schrieb:
I've been using clamav's clamd under cygwin and noticed that over time
the handle count as viewed with TaskManager seems to grow to arbitrary
values. I used clamd's option IdleTimeout set to 600 seconds which
dramatically reduced the growth rate of the Handle Count. Of co
I've been using clamav's clamd under cygwin and noticed that over time the
handle count as viewed with TaskManager seems to grow to arbitrary values.
I used clamd's option IdleTimeout set to 600 seconds which dramatically
reduced the growth rate of the Handle Count. Of course clamd has many
th
On Wed, 22 Sep 2004 13:57:26 +0100, Dave Korn wrote:
>> So could someone who got the _successful_ run of sig_bug.exe with recently
>> (>1.5.7-1) releases or snapshots of cygwin1.dll send it
>> (sig_bug.exe) to my personal e-mail?
>
> Well, here you go; source as well, just in case you have mor
> -Original Message-
> From: cygwin-owner On Behalf Of Valery A. Frolov
> Sent: 21 September 2004 22:52
> I've checked it and got the same bad result (crash) on 2000,
> XP and Win98.
>
> I've installed cygwin bundle for compilation of sig_bug.c on XP, compiled
> sig_bug.c to sig_bug.exe
> Maybe the operating system is the essence. I've always tried it on NT 4.0
> WS SP6a+hotfixes. Tomorrow I'll check it (the same executable) on 2000/XP.
I've checked it and got the same bad result (crash) on 2000, XP and Win98.
I've installed cygwin bundle for compilation of sig_bug.c on XP, comp
On Mon, 20 Sep 2004 10:35:48 -0400, Christopher Faylor wrote:
> FWIW, I tried it ten times without error. I have it running in a loop
> now. If it dies, I'll fix the problem.
But I had _no_ one successful run at all.
Maybe the operating system is the essence. I've always tried it on NT 4.0
WS SP
> -Original Message-
> From: cygwin-owner On Behalf Of Christopher Faylor
> Sent: 20 September 2004 15:36
> On Sun, Sep 19, 2004 at 11:17:28PM -0700, Yitzchak
> Scott-Thoennes wrote:
> >On Fri, Sep 17, 2004 at 10:08:31AM +0100, Dave Korn wrote:
> >>No SEGV for me. -lpthread didn't seem n
On Sun, Sep 19, 2004 at 11:17:28PM -0700, Yitzchak Scott-Thoennes wrote:
>On Fri, Sep 17, 2004 at 10:08:31AM +0100, Dave Korn wrote:
>>No SEGV for me. -lpthread didn't seem necessary. I'm using a version
>>of the cygwin1.dll built from CVS sources on 20041407.
>
>did you try it more than once? I
On Fri, Sep 17, 2004 at 10:08:31AM +0100, Dave Korn wrote:
> No SEGV for me. -lpthread didn't seem necessary. I'm using a version of
> the cygwin1.dll built from CVS sources on 20041407.
Wow, that's a lot more advanced than any snapshot I've seen. I'm
curious to know what version it reports.
> -Original Message-
> From: cygwin-owner On Behalf Of Valery A. Frolov
> Sent: 16 September 2004 20:15
> >> And after while I've got (IMHO) a little test source (attached) to
> >> reproduce the problem.
> >
> > Can anyone confirm this problem?
>
> So, after week of silence I can make th
>> And after while I've got (IMHO) a little test source (attached) to
>> reproduce the problem.
>
> Can anyone confirm this problem?
So, after week of silence I can make the decision that this problem has
been happened only for me (because no one has confirmed it). Anyway,
many many thanks for al
Hello,
On Mon, 30 Aug 2004 13:43:50 +0300, Valery A. Frolov wrote:
> And after while I've got (IMHO) a little test source (attached) to
> reproduce the problem.
Can anyone confirm this problem?
I've tested my testcase source (see previous letter) with cygwin1.dll
1.5.11-1, gcc 3.3.3-3, binutils-
On Fri, Aug 27, 2004 at 09:11:56PM +0300, Valery A. Frolov wrote:
>In short:
>First signal delivery on call of pthread_kill(tid, SIGUSR1) works fine
>but second one delivers signal with _delay_ and _twice_, and then my
>own daemon crash. This is on cygwin1.dll 1.5.10-3 and snapshot of
>2004-08-21.
> Whole trace files (strace7.log & straceB.log) are attached to this letter.
Heh... Forgot attach it.
WBR,
Valery
13:03:41 [main] yolopd 161 sigproc_init: process/signal handling enabled(1)
13:03:41 [main] yolopd 161 wait_for_sigthread: wait_sig_inited 0x54
13:03:41 [main] yolopd 161 subproc_ini
1 - 100 of 207 matches
Mail list logo
