RE: Long Parse Time

> > In this case, you can add your own timing info like this:
> >
> > tail -f the_trace_file | perl -nle 'print time, $_'
>
> I think this would suffer from write buffering effect, tail doesn't dump out
> data immediately when the write happens and pipes also have some buffering
> in them. I once hacked a library which hijacked write calls to tracefiles
> using LD_PRELOAD and did something similar. Not too practical for producting
> environments though so better stick with stack tracing :)

You're absolutely right about the sleep interval in running tail. For some reason, most implementations hard code that to 1 second. For a long time, I thought only GNU tail allows you to change it (option -s). I just searched tail.c on koders.com (GNU utils site?) and opensolaris.org. Both have this interval option now. But the tail command on my Solaris box (Solaris 9) still doesn't support it. On my Linux box, I can do tail -s 0.01 -f ....

At least now, the programmer of tail.c knows when following a file (-f), the buffer must be flushed. See line 284 of http://www.koders.com/c/fid57005A9F6FA610A020B35A7A87C405946121BE07.aspx?s=sort and line 1092 of
http://cvs.opensolaris.org/source/xref/sfw/usr/src/cmd/coreutils/coreutils-6.7/src/tail.c It would be an obvious programming mistake if that were not done.

Pipe buffer is not the same as, e.g., TCP buffer or dbms_output buffer (where before the buffer is full, you see nothing coming out), in the sense that 99% of the time when we use a UNIX pipe, a reader that can drain the buffer already awaits. Although we have a few KB pipe buffer (from getconf), the reader immediately "extracts" (reads) what's in the buffer. The buffer does have the other use, i.e. when it's full, the writer blocks.

Yong Huang       

--
http://www.freelists.org/webpage/oracle-l