[pa3efu@yahoo.com: Re: setvbuf/setlinebuf issue] Thomas can you comment?

Christopher Faylor cgf@redhat.com
Fri Sep 19 04:52:00 GMT 2003


I was getting ready to roll out a 1.5.5 release and then I rememebered
this problem.

Thomas, can you comment on this?

cgf

----- Forwarded message from Jan Jaeger <pa3efu@yahoo.com> -----

From: Jan Jaeger <pa3efu@yahoo.com>
To: cygwin@cygwin.com
Subject: Re: setvbuf/setlinebuf issue
Date: Wed, 17 Sep 2003 10:44:16 -0700 (PDT)
Mail-Followup-To: cygwin@cygwin.com

The issue appears related to the use of the pthread
library, where is almost appears if every thread now
has its own streams buffer, rather then a shared
buffer as the threading model dictates.

In the belowlisted sample, the 'main' thread creates a
logger thread which issues the setvbuf and
subsequently signals a condition that the main thread
is waiting on.
When the main thread resumes and it issues printf()'s
these are not line buffered as requested in the logger
thread.  
The test case should display test1 and test 2, wait
for 5 seconds and then display test2, instead it
displays test 1, then is waits, then test2 and test3
are displayed, eventhough there is no sleep between
test 1 and test 2.
What is not in this testcase, is that any printf()
from any other thread is not line buffered once again,
so the it appears that the buffering indicator has
become thread dependent, rather then stream dependent.

Thanks, 

Jan Jaeger

Test case:

#include <unistd.h>
#include <stdio.h>
#include <signal.h>
#include <pthread.h>

static pthread_attr_t  logger_attr;
static pthread_cond_t  logger_cond;
static pthread_mutex_t  logger_lock;
static pthread_t   logger_tid;


static int pipefd[2];

void *logger_thread(void *arg)
{
int n;
char buffer[80];


  setvbuf(stdout, NULL, _IOLBF, 0); // *** THIS DOES
NOT WORK PROPERLY ***

  pthread_mutex_lock(&logger_lock);
  pthread_cond_signal(&logger_cond);
  pthread_mutex_unlock(&logger_lock);

  while(1)
  {
    n = read(pipefd[0], buffer, sizeof(buffer));
    buffer[n] = '\0';
    fprintf(stderr,buffer);
  }
}

main()
{

  pipe(pipefd);
  dup2(pipefd[1],STDOUT_FILENO);

  pthread_attr_init(&logger_attr);
  pthread_attr_setstacksize(&logger_attr,1048576);
 
pthread_attr_setdetachstate(&logger_attr,PTHREAD_CREATE_DETACHED);
  pthread_cond_init (&logger_cond,NULL);
  pthread_mutex_init (&logger_lock,NULL);
  pthread_create (&logger_tid, &logger_attr,
logger_thread, NULL);
  pthread_mutex_lock(&logger_lock);
  pthread_cond_wait(&logger_cond,&logger_lock);
  pthread_mutex_unlock(&logger_lock);


//setvbuf(stdout, NULL, _IOLBF, 0);

printf("test1\n");
fflush(stdout);

printf("test2\n");
sleep(5);

printf("test3\n");
fflush(stdout);

sleep(5);

pthread_kill(logger_tid,SIGKILL);
fprintf(stderr,"done\n");
}

============================================================================================================
From: Christopher Faylor <cgf-rcm at cygwin dot com> 
To: cygwin at cygwin dot com 
Date: Tue, 16 Sep 2003 16:04:00 -0400 
Subject: Re: setvbuf/setlinebuf issue 
References:
<20030916191331.85685.qmail@web40017.mail.yahoo.com> 
Reply-to: cygwin at cygwin dot com 

--------------------------------------------------------------------------------

On Tue, Sep 16, 2003 at 12:13:31PM -0700, Jan Jaeger
wrote:
>We have always used setvbuf(stdout, NULL, _IOLBF, 0)
to ensure that
>each line is read by the logger as it is written.
>
>However this has now stopped working in the current
release of cygwin,
>adding a fflush() after every printf() bypasses the
error, but at the
>moment setvbuf does not seem to work correctly for
us.

Do you have a simple test case which demonstrates
this?  I wrote the
below and piped it into cat and it works as expected. 
"foo" is printed,
there is a five second pause, and "bar is printed.

cgf

#include <stdio.h>
int
main (int argc, char **argv)
{
  setvbuf(stdout, NULL, _IOLBF, 0);
  printf ("foo\n");
  sleep (5);
  printf ("bar");
}



__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com

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

----- End forwarded message -----



More information about the Cygwin-developers mailing list