Experimental Physics and
Industrial Control System

Andrew Johnson <[email protected]> · Mon, 3 Nov 2008 16:03:00 -0600

On Monday 03 November 2008 15:25:45 Eric Norum wrote:
> On Nov 3, 2008, at 2:40 PM, Andrew Johnson wrote:
> >
> >    How important is it that errlogPrintf() and friends directly call
> >    fprintf(stderr) when called in a thread that is allowed to block?
> >
> >    My inclination would be to do what Lewis proposes and do all the
> >    console output from the errlogThread, but that would often cause
> >    the example above to output "A", "C" and then later "B".
>
> The decision comes down to how heavily you weight the expectations
> that you mention in the first paragraph above.  As you pointed out,
> the developer's guide does state (or at least imply pretty strongly)
> that
>   	printf("A\n");
> 	errlogPrintf("B\n");
> 	printf("C\n");
> will generate "A" "B" and "C" in order.  Now this promise is to be
> rescinded.

It doesn't have to be; it wouldn't be hard to keep the existing fprintf() code 
in errlogPrintf(), removing its call to errlogVprintf(), and arrange for 
errlogVprintf() to pass its converted buffer to fprintf() if blocking is 
allowed.  That would be better than we have now and the only strange behavior 
would be that the 256 byte length limitation doesn't apply to the console 
output from errlogPrintf().

> I think that it is fairly easy to argue that there should not be any
> expectation that errlogPrintf output appear in any fixed relation to
> printf/fprintf output.

Doing so would certainly simplify the code in errlog.c, making it easier to 
maintain.  However I'm still willing to listen to objections.

- Andrew
-- 
Talk is cheap. Show me the code. -- Linus Torvalds

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System