Confirmed users
398
edits
TaskTracer: Difference between revisions
Jump to navigation
Jump to search
Add information of the design
m (→Labels) |
(Add information of the design) |
||
| Line 116: | Line 116: | ||
console.log("#tt# Log message"); // #tt# is the prefix. | console.log("#tt# Log message"); // #tt# is the prefix. | ||
== DESIGN == | |||
TaskTracer has 5 types of logs in its log files, | |||
DISPATCH, BEGIN, END, VTABLE, and LABEL. | |||
They are used to remember | |||
- what the task created and dispatched a new task an dispatch it to | |||
a target thread, | |||
- the time a task was started to run at the target thread, | |||
- the time a task had done its works, | |||
- the type (vtalbe of the class) of the runnable of a given task, and | |||
- labels that denote what was happened in a task. | |||
=== TASK ID === | |||
Each type of logs has a time stamp to denote when it was happened, and | |||
a task ID to uniquely identify a tasks. To make the running code | |||
knowning which task is running at a thread, the ID of the running task | |||
is stored in the TLS, e.q. thread local storage, when the event loop | |||
of the thread starts to run it. That means when a new task was | |||
created and dispatched, TaskTracer got the task ID of the running task | |||
of current thread from TLS, and denote it as the creator/parent of the | |||
new one. | |||
The IDs of a task and its parent task (from TLS) were recorded in a | |||
DISPATCH log when it was dispatched to correlates a task and its | |||
parent task. | |||
When an IPC message was sent, a new task was created and dispatched at | |||
receiving side to handle the message. TaskTracer stores the task ID | |||
of the sender of a message in its header, and uses that ID as the | |||
parent task ID of the task handling the message at receiving site. | |||
With this, TaskTracer correlates tasks over processes. | |||
=== SOURCE EVENT ID AND TYPE === | |||
Not all tasks are always created by another task. For example, a | |||
mouse event would create and dispatch a task to handle it, but the | |||
mouse event itself is no task. TaskTracer calls mouse events or other | |||
events from the kernel as source events. Every source event has an | |||
unique ID to identify it, and assign a type to identify whether it is | |||
a mouse event, keyboard event, ..., or network event. They are source | |||
event IDs and source event types. | |||
The tasks created by source events have no parent task ID, the value of | |||
its parent task ID is identical to its task ID. With this rule, users | |||
know a task was created for handling a source event if its task ID is | |||
identical to its parent task ID. | |||
Source event ID and type would be stored in TLS of threads. They are | |||
also retrieved from TLS and stored in the new runnable of a new task | |||
when the new task is created/dispatched. When a new task was started | |||
to run, the source event ID and type stored on it will be retrieved | |||
and stored to TLS too. That means source event ID and type would | |||
passing along all tasks created for the source event directly or | |||
indirectly. That means they are also dispatched along IPC messages. | |||
=== VTABLE === | |||
For C++, every virtual class, that means a class having at least one | |||
virtual method, has a vtab to store entry points of its virtual | |||
methods. A VTABLE log contains the address of vtab of the concrete | |||
class of an instance of Runnable (a task). With the address of the | |||
vtab of a task, TaskTracer can get the concrete class name of the task | |||
by symbolicating. People can understand the purpose of a task by its | |||
name. | |||