Version: trunk @ r422460.

TRACE_TASK_EXECUTION() uses all (both) AddTraceEvent parameters to record src_file and src_func. This is problematic because task sites that desire to record more information can't.

[Splitting from  issue 649084  as I now intend to solve that issue without addressing this one which is getting too involved as highlighted below]

One idea is to lump both src_file and src_func in a single ConvertableToTraceFormat object (https://codereview.chromium.org/2374193002). This works and would allow task sites that desire to tack on their custom information in another ConvertableToTraceFormat parameter (e.g. https://codereview.chromium.org/2356393002/).

Issues identified with doing this:

 1) skyostyil: Many existing tools depend on parsing src_file/src_func as it's recorded today:
               https://cs.corp.google.com/search/?q=%5C%22src_file%5C%22+%5C%22src_func%5C%22&type=cs

 2) primiano: "This is going to cause heap traffic on each task":
 True, the alternatives are:
  a) Allow ConvertableToTraceFormat to be passed by value (and make PendingTask
inherit ConvertableToTraceFormat directly).
     For thread-safety, the tracing system would have to extract the string
synchronously (which would result in the same number of bytes being copied as
today where two strings are passed by value).
  b) Add "std::string PendingTask::GetTracingInfo()" and hand a string directly
to the tracing system that contains both src_file and src_func.

Benefits of doing this:
 
 1) As mentioned: allow optional extra args on task's trace event (instead of requiring a second trace event for the same thing)
 2) Facilitates making recording of src_file/src_func optional (behind its own category).
 

Version: trunk @ r422460.

TRACE_TASK_EXECUTION() uses all (both) AddTraceEvent parameters to record src_file and src_func. This is problematic because task sites that desire to record more information can't.

[Splitting from  issue 649084  as I now intend to solve that issue without addressing this one which is getting too involved as highlighted below]

One idea is to lump both src_file and src_func in a single ConvertableToTraceFormat object (https://codereview.chromium.org/2374193002). This works and would allow task sites that desire to tack on their custom information in another ConvertableToTraceFormat parameter (e.g. https://codereview.chromium.org/2356393002/).

Issues identified with doing this:

 1) skyostyil: Many existing tools depend on parsing src_file/src_func as it's recorded today:
               https://cs.corp.google.com/search/?q=%5C%22src_file%5C%22+%5C%22src_func%5C%22&type=cs

 2) primiano: "This is going to cause heap traffic on each task":
 True, the alternatives are:
  a) Allow ConvertableToTraceFormat to be passed by value (and make PendingTask
inherit ConvertableToTraceFormat directly).
     For thread-safety, the tracing system would have to extract the string
synchronously (which would result in the same number of bytes being copied as
today where two strings are passed by value).
  b) Add "std::string PendingTask::GetTracingInfo()" and hand a string directly
to the tracing system that contains both src_file and src_func.

 3) It breaks the search feature of chrome://tracing which doesn't appear to find strings
    inside JSON objects reported by a ConvertableToTraceFormat object.

Benefits of doing this:
 
 1) As mentioned: allow optional extra args on task's trace event (instead of requiring a second trace event for the same thing)
 2) Facilitates making recording of src_file/src_func optional (behind its own category).