This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: stpd and stdout
- From: Martin Hunt <hunt at redhat dot com>
- To: Hien Nguyen <hien at us dot ibm dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>
- Date: Thu, 18 May 2006 10:56:55 -0700
- Subject: Re: stpd and stdout
- Organization: Red Hat Inc.
- References: <446115E6.4000302@us.ibm.com>
On Tue, 2006-05-09 at 15:21 -0700, Hien Nguyen wrote:
> Hi Martin,
>
> While working on the the systemtap GUI we run into the problem of
> getting the stdout to the gui app in a timely fashion. We does get the
> output as a blob of text once in a while (looks like data were only
> flushed out when the buffer is full). To recreate the problem you can
> try this
>
> stap -e 'probe syscall.open{ log(filename) }' | tee
>
> Anyway, I added one line of code to flushout the data as soon as the
> stpd gets it. It seems to solve the above problem. To avoid unnecessary
> performance issues for others, perhaps we should have that as an option.
> What do you think?
I think that in this case (stdout from procfs) it should always be
line-buffered. No option is necessary. In fact I tried it and couldn't
measure any significant performance advantage for full buffering. I've
gone ahead and committed the following patch. Let me know how it works.
Index: librelay.c
===================================================================
RCS file: /cvs/systemtap/src/runtime/stpd/librelay.c,v
retrieving revision 1.37
diff -u -r1.37 librelay.c
--- librelay.c 8 Apr 2006 21:59:36 -0000 1.37
+++ librelay.c 18 May 2006 17:51:31 -0000
@@ -722,6 +722,7 @@
int type;
FILE *ofp = stdout;
+ setvbuf(ofp, (char *)NULL, _IOLBF, 0);
pthread_mutex_init(&processing_mutex, NULL);
signal(SIGINT, sigproc);