Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26419

Re: Delayed "printf"

Show all headers | View raw

On 25/04/17 07:19, Robert Wessel wrote:
> On Mon, 24 Apr 2017 19:42:30 -0500, Tim Wescott
> <seemywebsite@myfooter.really> wrote:
> 
>> Sometimes it's necessary to float a notion just so that someone can 
>> affirm your suspicion that yes, you really are an idiot.
>>
>> On the off chance that I'm a genius, though, here goes:
>>
>> I don't like putting "printf" in fast tasks for obvious reasons -- even 
>> with infinite spooling, it can take time to process a format string.  In 
>> my usual context, this can result in audible sounds from motors when I 
>> print some bit of debugging information from a high-priority task.  The 
>> problem can't be alleviated by spooling the output of the printf, because 
>> it's the execution time of the printf itself that's the problem.
>>
>> Just how dumb is it to have "printf" queue up the format string AND the 
>> parameters into a buffer, to be printed out in some low-priority task?  
>> For a system with sufficient memory, this seems like an astonishingly 
>> sensible thing to me.
>>
>> Clearly you'd have to wrap it up somehow so that if the buffer was full 
>> no printf at all would happen -- but I'm kinda liking the notion.
>>
>> So -- whatcha think?
> 
> 
> A problem is that finding all the input parameters, and copying them
> someplace, may well be a considerable amount of work.  *Output*
> parameters (%n, the return value), have already been mentioned, and
> pose significant additional problems.
> 
> While copying something like an integer or float is going to be fairly
> quick (assuming you have some place to put them already allocated),
> and likely rather faster than than actually formatting them, you're
> still going to have to do a non-trivial amount of parsing to actually
> *find* those parameters.  And remember you have not just the
> parameters, but the precision and min size can be specified as a
> parameter ("*").  With strings, you have a worse allocation problem,
> and copying the strings to a temporary area is going to be as much
> work as actually processing them.
> 
> So at best, you're likely to only save a modest amount of CPU time in
> the issuing thread formatting the output string, and quite possibly
> that CPU usage in the main thread may be a non-trivial amount worse.
> Overall CPU usage will certainly be worsened considerably.
> 
> OTOH, your real goal is to prevent the printf from blocking because it
> lacks output space.
> 
> A simple way to do that is to perform an snprintf to a pre-allocated,
> and fairly fixed size, buffer, and then pass *that* buffer to a
> separate thread for output.  A better option may be to issue an
> asynchronous I/O request (although you'll have to step outside of C
> streams at that point).  If the available buffer is too small, you
> have the choice of ignoring the output, or truncating it, and you have
> several options for dealing with a new output request from the main
> thread that happenes before the old buffer is disposed of (ignore,
> block, have multiple available output buffers).
> 
> An advantage of doing the snprintf in the main thread, is that you
> largely leave the semantics of printf unchanged.

The problem with this approach is that snprintf is still doing most of
the work that printf does - it is still a slow function.

> 
> You can sometimes also check (OS dependent) if there is space in the
> stream output buffer (__fbufsize and __fpending in *nix, for example),
> and use that to judge whether you're going to have room for the output
> (you could do a trial with snprintf and a zero length buffer to get
> the length required, for example).  You then need to compensate for
> things like expansion of newlines (OS dependent, of course, not an
> issue in *nix*).
> 

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Delayed "printf" Tim Wescott <seemywebsite@myfooter.really> - 2017-04-24 19:42 -0500
  Re: Delayed "printf" Don Y <blockedofcourse@foo.invalid> - 2017-04-24 18:51 -0700
    Re: Delayed "printf" Tim Wescott <tim@seemywebsite.com> - 2017-04-24 21:54 -0500
      Re: Delayed "printf" Don Y <blockedofcourse@foo.invalid> - 2017-04-24 21:27 -0700
  Re: Delayed "printf" Paul Rubin <no.email@nospam.invalid> - 2017-04-24 19:53 -0700
  Re: Delayed "printf" Clifford Heath <no.spam@please.net> - 2017-04-25 13:01 +1000
    Re: Delayed "printf" Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-04-25 18:51 +0100
      Re: Delayed "printf" Clifford Heath <no.spam@please.net> - 2017-04-26 12:59 +1000
        Re: Delayed "printf" Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-04-26 13:24 +0100
  Re: Delayed "printf" Robert Wessel <robertwessel2@yahoo.com> - 2017-04-25 00:19 -0500
    Re: Delayed "printf" David Brown <david.brown@hesbynett.no> - 2017-04-25 10:44 +0200
      Re: Delayed "printf" Robert Wessel <robertwessel2@yahoo.com> - 2017-04-25 09:22 -0500
        Re: Delayed "printf" David Brown <david.brown@hesbynett.no> - 2017-04-25 16:37 +0200
    Re: Delayed "printf" Tim Wescott <tim@seemywebsite.com> - 2017-04-25 10:49 -0500
  Re: Delayed "printf" Jack <jack4747@gmail.com> - 2017-04-24 23:33 -0700
  Re: Delayed "printf" Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-04-25 08:09 +0100
  Re: Delayed "printf" John Devereux <john@devereux.me.uk> - 2017-04-25 08:14 +0100
  Re: Delayed "printf" David Brown <david.brown@hesbynett.no> - 2017-04-25 10:58 +0200
  Re: Delayed "printf" Stefan Reuther <stefan.news@arcor.de> - 2017-04-25 18:46 +0200
  Re: Delayed "printf" Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2017-04-25 21:03 +0200
  Re: Delayed "printf" Tim Wescott <seemywebsite@myfooter.really> - 2017-04-25 16:11 -0500
    Re: Delayed "printf" Les Cargill <lcargill99@comcast.com> - 2017-04-25 17:28 -0500
    Re: Delayed "printf" Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-04-26 10:03 +0300
  Re: Delayed "printf" Dave Nadler <drn@nadler.com> - 2017-04-25 14:31 -0700
  Re: Delayed "printf" Les Cargill <lcargill99@comcast.com> - 2017-04-25 17:25 -0500
  Re: Delayed "printf" mac <acolvin@efunct.com> - 2017-04-26 17:22 +0000
    Re: Delayed "printf" Grant Edwards <invalid@invalid.invalid> - 2017-04-26 17:37 +0000
      Re: Delayed "printf" Grant Edwards <invalid@invalid.invalid> - 2017-04-26 17:38 +0000

csiph-web