Your code does not seem to do anything to validate that the length of the
data returned by readv is indeed what you expected.
- Mark Pizzolato
--
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/
On Sunday, June 12, 2005 T 5:37 PM, Mark Pizzolato wrote:
On Friday, June 10, 2005 at 3:44 PM, Mark Pizzolato wrote:
> On Thursday, June 09, 2005 at 6:12 PM, Mark Pizzolato wrote:
>> On Thursday, June 09, 2005 at 3:35 PM, Christopher Faylor wrote:
>> > On Wed, Jun 08, 2005 a
On Friday, June 10, 2005 at 3:44 PM, Mark Pizzolato wrote:
> On Thursday, June 09, 2005 at 6:12 PM, Mark Pizzolato wrote:
>> On Thursday, June 09, 2005 at 3:35 PM, Christopher Faylor wrote:
>> > On Wed, Jun 08, 2005 at 05:43:59PM -0700, Mark Pizzolato wrote:
>> > >
On Thursday, June 09, 2005 at 6:12 PM, Mark Pizzolato wrote:
On Thursday, June 09, 2005 at 3:35 PM, Christopher Faylor wrote:
> On Wed, Jun 08, 2005 at 05:43:59PM -0700, Mark Pizzolato wrote:
> >There is a serious problem for multi threaded programs doing simple I/O
> >operations
On Thursday, June 09, 2005 at 3:35 PM, Christopher Faylor wrote:
On Wed, Jun 08, 2005 at 05:43:59PM -0700, Mark Pizzolato wrote:
>There is a serious problem for multi threaded programs doing simple I/O
>operations in cygwin (open, dup, fdopen, fclose, and close).
>
>The attached
that anyone who ever encountered a stange hang in any program
running under cygwin would appreciate a fix for this issue.
- Mark Pizzolato
#include
#include
#include
#include
#include
#include
pthread_mutex_t log_mutex = PTHREAD_MUTEX_INITIALIZER;
void
logit(const char *fmt, ...) {
va
The attached example test program runs to completion when run directly, but
spins infinitely when run under gdb.
I'm compiling with:
gcc -g -O0 mutexttest.c -o mutexttest
running under:
cygwin1.5.17-1
gdb 20041228-3
#include
#include
#include
#include
pthread_mutex_t l
clamd 3772 sigproc_terminate: entering
147 672076435 [sig] clamd 3772 proc_terminate: n
Thanks for any comments, observations or advise.
- Mark Pizzolato
--
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/
ried to look at the code for fopen(),dup(), and fdopen() myself before
reporting this, but I can't find the implementations of these system calls
in the source package for cygwin-1.5.13-1
Can someone point me to where I can look at the source code?
Thanks.
- Mark Pizzolato
--
Unsubscribe info
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 arbitr
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
&g
ugh with cygwin internals to
help get this problem under control.
- Mark Pizzolato
#include
typedef enum _PROCESSINFOCLASS {
ProcessHandleCount = 20,
} PROCESSINFOCLASS;
typedef LONG NTSTATUS;
int
GetHandleCount()
{
static NTSTATUS
(*lpNtQueryInformationProcess)(
ts to "Assume -R" for several files, but not all of the patches
can be applied anyway. Then things go on to get worse. This should
probably be addressed by someone who created the patches in the package.
- Mark Pizzolato
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
13 matches
Mail list logo
