Re: Implementing a generic binary trace interface.

[Tom Zanussi <zanussi at us dot ibm dot com>]

Martin Hunt writes:
 > If I understand it correctly, you propose getting a buffer, having
 > numerous trace() calls, which the translator directly writes into the
 > buffer, then a call to the runtime to send the accumulated trace data?
 > How would this interact with normal ASCII data (if you mix printf() with
 > trace())? Also how do you specify the format of the data stored?
 > 

Sorry, I've been occupied with other things, so haven't been able to
spend much time on this...

Anyway, the gist of it was that it with some language support, it
should be possible to have the translator generate the most efficient
code possible for logging variable-length trace records, which in many
cases would be a high-frequency occurence and so, worth optimizing.

I assumed we could add a transport-independent run-time function
called say _stp_reserve() which would reserve a slot of a given length
in the current 'trace buffer' whatever that might be for a given
transport.  The translator would have enough info from the set of
trace() calls Frank suggested to 1) calculate the size of the slot
needed to reserve space in the buffer and 2) generate the code that
would write the result of the trace() calls into the reserved slot.
There shouldn't need to be a 'flush' or anything else after the last
trace(), because the data would already be in its final destination.
I think Frank also suggested this could be done using something like
your trace syntax.

As for mixing the normal ASCII data and binary data, maybe it makes
more sense to not have to deal with that at all and use separate
streams for each...