Brian Ford wrote:
On Fri, 21 May 2004, John William wrote:
I tried the cygwin.dll snapshot dated 2004-05-20 and it still outputs
interleaved text with multiple threads and vprintf()/vsprintf() crash when
called from multiple threads and not protected with mutex_lock() and
mutex_unlock() calls aroun
Dave Korn wrote:
Ah, thanks for the info. I noticed that a few people have been working on
it lately, including yourself and Thomas Pfaff, so I was hoping that any
known problems or workrounds might be fresh in people's minds. May I ask if
whoever last was maintainer left any notes or
Arash Partow wrote:
Hi All,
I'm writing about another issue I've found with cygwin layer, pthreads,
memory leaks. I've updated to the lastest g++, currently I'm using
the cygwin1.dll from 8th Nov.
Now the issue is that the ThreadTest (url to source available below) is now
leaking a "HUGE!" amount
Hi Arash,
i downloaded TaskInfo, installed it on a 2,5 GHz P4 W2000 box, tried
free RAM (slow and fast) and your Test did not crash. I rebuilded the
cygwin DLL while your test was running, still no crash.
If you are interested to dig a little deeper download the snapshot
source and build your
Arash Partow wrote:
Greetings to Thomas and all others involved in cygwin pthreads
implementation,
I've downloaded the snapshots of cygwin1.dll (cygwin1-20031025.dll.bz2 and
cygwin1-20031027.dll.bz2), I think the prior is the one where Thomas made
changes and in the latter Corinna made changes to s
Arash Partow wrote:
The prototype initially creates 700 threads all of which are contained in a
vector (threadList), each thread does some "simple" string processing
(basically tokenize a string) and then exists. On completion of the thread,
the thread sets its own state in the thread-class to dead
Joost Kraaijeveld wrote:
Hi Thomas,
Sorry for contacting you outside the Cgwin mailing list directly but I
am really desperate for an answer. I searched the mailinglist, Googled,
read the IEEE specs, studied several PThread implementations, actually
ran the code on BSD, Linus, Solaris and Cygwin b
After upgrading my cygwin release box from 1.33.2 to 1.5.3 i see a
strange cut and paste probleme between xemacs 21.4.13 and windows.
Cut and paste from and to windows works as long as xemacs does not fork
a child process. After a fork of a shell, gdb or gnuserv the actual
clipboard content is
> I would like to use this function down to 10 milliseconds accuracy if
> possible.
> However upon looking at winsup/cygwin/thread.cc,
> it uses the function "ftime" and the millisecond field is ignored.
This is already fixed. Try the snapshot.
Bit do not expect that you can use it with 10 ms del
Robert Collins wrote:
Because the results are undefined, you are permitted to return EBUSY...
Linux and Solaris do not return an error when the attr is already
initialized, therefore i will do the change to return 0.
The code must be changed anyway, since some attr_init functions
erroneously ret
Rasmus Hahn wrote:
Hi Thomas,
Problem solved: it was not the mutex but the but the pthread_mutexattr_t
that caused the error. cygwin's pthread_mutexattr_init () function checks
if its argument points to a valid object. If the pthread_mutexattr_t's
value still points to a valid object (from a prev
Rasmus Hahn wrote:
On Tue, Jun 10, 2003 at 09:25:43AM +0200, Thomas Pfaff wrote:
Rasmus Hahn wrote:
Hello,
i am using cygwin on my Windows2000 and my c++ program segfaults
when using pthread-mutexes. In particular i am using a lot of
mutexes from within constructors of static objects. These
Rasmus Hahn wrote:
Hello,
i am using cygwin on my Windows2000 and my c++ program segfaults
when using pthread-mutexes. In particular i am using a lot of
mutexes from within constructors of static objects. These constructors
are called at a very early time of execution of the program and do
calls
Brian Ford wrote:
On Fri, 28 Mar 2003, Thomas Pfaff wrote:
Brian Ford wrote:
It is failing with:
Assertion failed: (awoken == NUMTHREADS - canceledThreads), file
/home/ford/downloads/cygwin/winsup/testsuite/winsup.api/pthread/condvar9.c,
line 229
A simple debug shows:
pthread/condvar9.c: awoken 8
Brian Ford wrote:
I have been seeing this for a few days now. I will investigate further
when I have more time, but I thought I would give Thomas Pfaff and others
a heads up.
It is failing with:
Assertion failed: (awoken == NUMTHREADS - canceledThreads), file
/home/ford/downloads/cygwin/winsup
Gerrit P. Haase wrote:
Thomas schrieb:
Gerrit P. Haase wrote:
Thomas schrieb:
Gerrit P. Haase wrote:
Hallo perl5-porters,
successfully builded bleadperl with threads the first time,
many thanks to the Wizard of Perl!
I was able to build perl 5.8.0-1 with threads that has passed all tests
Gerrit P. Haase wrote:
Thomas schrieb:
Gerrit P. Haase wrote:
Hallo perl5-porters,
successfully builded bleadperl with threads the first time,
many thanks to the Wizard of Perl!
I was able to build perl 5.8.0-1 with threads that has passed all tests
by disabling perls internal malloc. With the
Gerrit P. Haase wrote:
Hallo perl5-porters,
successfully builded bleadperl with threads the first time,
many thanks to the Wizard of Perl!
$ cat /ftproot/pub/mirror/bleadperl/.patch
19013
Cygwin Package Information
Package Version
cygwin 1.3.22-1
Tests were all success
Brian Ford wrote:
I get the following error repeatedly in 1.3.19 when I try to use thread
priorities and pthread_condition_signal:
128327 [unknown (0x9D8)] vital 3032 pthread_cond::Signal: Released too
many threads - 1 now 1 originally
Any idea what the problem is? I will continue trying to track
Joe Sadusk wrote:
I'm in qa, and I'm attempting to port a filesystem stress test written
for Linux to Windows using cygwin. It uses pthreads to create many
concurrent threads which read files out of a directory in various
patterns. The thing is, I've found that with any more than 55 threads,
Please check the sem_init return code first.
Cygwin does not support process shared semaphores at the moment.
Thomas
Elliot Mednick wrote:
Hello,
I'm try to write a client server application that used shared memory and
asemaphores. Appended is a simple test case. It works under Solaris
using
Instead of renaming the files create links:
ln -s gcc-2.exe gcc.exe
ln -s g++-2.exe g++.exe
...
If your fs is ntfs you can also create hard links
Thomas
David K. McAllister wrote:
Today I updated my cygwin install for the first time in about three
months. Apparently I unwittingly installed gcc
Sorry, I forgot to mention:
Your work around is not portable. The type of sem_t is not necessary a
pointer.
Portable would be something like:
memset(&sem, 0, sizeof(sem));
Thomas
Thomas Pfaff wrote:
Just add a breakpoint after the sem_init call.
To avoid multiple initializations sem_
Just add a breakpoint after the sem_init call.
To avoid multiple initializations sem_init checks if the semaphore is
already initialized and will return EBUSY in that case.
The check is done via IsBadWritePtr which will trigger a SEGV if the
pointer is invalid and not NULL.
The SEGV is handled in
Christopher Faylor wrote:
On Wed, Nov 20, 2002 at 10:14:59AM +1100, Nigel Stewart & Fiona Smith wrote:
Michael,
I have encountered the same problem on my setup.
Regards,
I have not encountered the same problem in my setup.
HTH,
cgf
I have the same problem and i suspect that this is due
Dr. M. C. Nelson wrote:
Dear mailing list:
The following code works well on a Linux platform,
int sockfd;
char buf[1024];
struct sockaddr fromaddr;
int fromlen;
if ( (retv = recvfrom( sockfd, buf, sizeof(buf), 0, &fromaddr,&fromlen )) <
0 )
{
perror( "udpclient: recvfrom" );
Franck Leray wrote:
Hi all,
A process waiting for clients on a 'accept' statement becomes mad (eating cpu) when it receives a signal.
Not on UNIX platform.
See the message of Christopher Faylor (28 jun 2002) '1.3.11: accept ist not interrupted by a signal' for an example.
This has been fixed
27 matches
Mail list logo
