public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* Re: setvbuf/setlinebuf issue
@ 2003-09-17 17:57 Jan Jaeger
  0 siblings, 0 replies; 5+ messages in thread
From: Jan Jaeger @ 2003-09-17 17:57 UTC (permalink / raw)
  To: cygwin

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/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: setvbuf/setlinebuf issue
  2003-09-17 18:39 Brian Ford
@ 2003-09-17 21:39 ` Christopher Faylor
  0 siblings, 0 replies; 5+ messages in thread
From: Christopher Faylor @ 2003-09-17 21:39 UTC (permalink / raw)
  To: cygwin, newlib

On Wed, Sep 17, 2003 at 12:57:10PM -0500, Brian Ford wrote:
>Jan Jaeger wrote here:
>
>http://www.cygwin.com/ml/cygwin/2003-09/msg01159.html
>
>> 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.
>>
>This problem appears analogous to the at_exit problem in newlib fixed by
>Thomas Pfaff here:
>
>http://sources.redhat.com/ml/newlib/2003/msg00527.html
>
>I assume a similar fix is in order, but I don't currently have to time to
>cook one up and test it.  Is anyone else game?

Except that, I thought that Thomas already fixed this in newlib some time
ago.

cgf

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: setvbuf/setlinebuf issue
@ 2003-09-17 18:39 Brian Ford
  2003-09-17 21:39 ` Christopher Faylor
  0 siblings, 1 reply; 5+ messages in thread
From: Brian Ford @ 2003-09-17 18:39 UTC (permalink / raw)
  To: cygwin; +Cc: newlib

Jan Jaeger wrote here:

http://www.cygwin.com/ml/cygwin/2003-09/msg01159.html

> 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.
>
This problem appears analogous to the at_exit problem in newlib fixed by
Thomas Pfaff here:

http://sources.redhat.com/ml/newlib/2003/msg00527.html

I assume a similar fix is in order, but I don't currently have to time to
cook one up and test it.  Is anyone else game?

I'll give it a try when I free up if no one else gets there first.  BTW, a
pass through newlib looking for other similar occurences appears to be in
order.

-- 
Brian Ford
Senior Realtime Software Engineer
VITAL - Visual Simulation Systems
FlightSafety International
Phone: 314-551-8460
Fax:   314-551-8444

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: setvbuf/setlinebuf issue
  2003-09-16 19:18 Jan Jaeger
@ 2003-09-16 20:04 ` Christopher Faylor
  0 siblings, 0 replies; 5+ messages in thread
From: Christopher Faylor @ 2003-09-16 20:04 UTC (permalink / raw)
  To: cygwin

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");
}
--
Please use the resources at cygwin.com rather than sending personal email.
Special for spam email harvesters: send email to aaaspam@sourceware.org
and be permanently blocked from mailing lists at sources.redhat.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/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* setvbuf/setlinebuf issue
@ 2003-09-16 19:18 Jan Jaeger
  2003-09-16 20:04 ` Christopher Faylor
  0 siblings, 1 reply; 5+ messages in thread
From: Jan Jaeger @ 2003-09-16 19:18 UTC (permalink / raw)
  To: cygwin

Hi List,
I am one of the developers of the hercules emulator
(http://www.conmicro.cx/hercules), and it seems that
we have hit a problem with setvbuf in more recent
cygwin versions.  

We capture all standard output by means of redirecting
stdout to a pipe, which is subsequently read by a
logger function.  (printf() to stdout, which then goes
to the pipe, read() by the logger function from the
pipe)

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.

What I find somewhat odd is that this only happens
when I recompile under the current cygwin.  If I use
an older binrary (created on backlevel cygwin) then
all works fine.

Has anyone experienced any similar problems with
streams buffering?

Thanks and regards,

Jan Jaeger

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2003-09-17 21:35 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-09-17 17:57 setvbuf/setlinebuf issue Jan Jaeger
  -- strict thread matches above, loose matches on Subject: below --
2003-09-17 18:39 Brian Ford
2003-09-17 21:39 ` Christopher Faylor
2003-09-16 19:18 Jan Jaeger
2003-09-16 20:04 ` Christopher Faylor

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).