# inviso_lfm_tpfreader

### MODULE

inviso_lfm_tpfreader

### MODULE SUMMARY

Inviso Standard Reader Process to Standard Logfile Merger

### DESCRIPTION

Implements the standard reader process to the standard logfile merger `inviso_lfm`.

The reader process reads logfiles belonging to the same set (normally one node) in chronological order and delivers logged trace messages one by one to the output process. Before any trace messages are delivered, the `inviso_lfm_tpreader` implementation reads the entire trace information file (if in use) and builds a database over pid-to-alias associations.

The `inviso_lfm_tpreader` implementation is capable of considering that an alias may have been used for several processes during different times. An alias may also be in use for several pids at the same time, on purpose. If a process has generated a trace message, all associations between that pid and aliases will be presented as the list `PidMappings` in the message sent to the output process.

### EXPORTS

`handle_logfile_sort_wrapset(LogFiles) -> FileList2`

Types:

`LogFiles = [{trace_log, FileList}]`
`FileList = FileList2 = [FileName]`
`FileName = string()`

Only one `{trace_log, FileList}` tuple is expected in `LogFiles`, all other tuples are ignored. `FileList` must:

- contain one single file name, or
- a list of wraplog files, following the naming convention `<Prefix><Nr><Suffix>`.

Sorts the files in `FileList` in chronological order beginning with the oldest. Sorting is only relevant if `FileList` is a list of wraplogs. The sorting is done on finding the modulo-counter in the filename and not on filesystem timestamps.

This function is exported for convenience should an own reader process be implemented.

### The Trace Information File Protocol

The format of a trace information file is dictated by the meta tracer process. The `inviso_lfm_tpfreader` implementation of a reader process understands the following trace information entries. Note that the `inviso_rt_meta` trace information file is on binary format prefixing every entry with a 4 byte length indicator.

`{Pid, Alias, alias, NowStamp}`
  `Pid = pid()`
  `Alias = term()`
  `NowStamp = term()`, but in current implementation as returned from `erlang:now/0`
  This message indicates that from now on shall `Pid` be associated with `Alias`.
`{MaybePid, Alias, unalias, NowStamp}`
  `MaybePid = pid() | undefined`
  `Alias = term()`
  `NowStamp = term()`, see above
  This message indicates that, if `MaybePid` is a pid, this pid shall no longer be associated with `Alias`. If it is `undefined`, all associations with `Alias` from now shall be considered invalid.
  Also note that there are many situations where `unalias` entries will be missing. For instance if a process terminates without making explicit function calls removing its associations first. This is seldom a problem unless the pid is reused.

### AUTHORS

Lennart Öhman - support@erlang.ericsson.se

inviso 0.4
Copyright © 1991-2007 Ericsson AB