Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pass to fixup definitions and add some content. #1

Merged
merged 10 commits into from
Jan 10, 2018
Merged

Pass to fixup definitions and add some content. #1

merged 10 commits into from
Jan 10, 2018

Conversation

mrkmarron
Copy link
Contributor

No description provided.

Copy link
Owner

@mike-kaufman mike-kaufman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks good. some comments. Feel free to address or just go ahead & merge in and we can discuss at some point.

every function. Thus, from a runtime viewpoint all of the functions are
part of the same asynchronous context regardless of which (logically
is implemented using JavaScript in Node core and uses a list of timer
callbacks to track _every_ function to be executed when a given timespan has elapsed. When the timespan expires a single synchronous function is called
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missed your 80-column goal here.

program execution but requires the use of _callback_ or _promise_ based code
to ensure applications remain responsive. Thus, understanding the behavior of
an application requires understanding the execution of several blocks of code
and how their executions are related via asynchronous callback interleavings
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

executions'

logically responsible (according to the `host` API)
for causing the execution of a previously **linked** _g_ from context _j_
we say _f<sub>i</sub>_ `causes` _g<sub>j</sub>_.
- **happens before** -- when a function _f_ in context _i_ is asynchronously
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does happens before need to be more generally defined in terms of context, and not just execution. E.g., "given two contexts fi and gj, we say fi happens before gj if and only if i < j."

point in program execution. For example, the following code
A **long call stack** is a list of call-stacks that span asynchronous callback
operations. Analagous to a synchronous callstack, "Long call stacks" are
useful for programmers to answer the question of "what was the call path to a specific point in program execution. For example, the following code
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

80 chars.

### Resource Use Monitoring with Traces
**TODO** fill this in

### Long Call-Stacks from Graphs
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was thinking that stuff like this would be in section 5. i.e., precisely how do you solve a given problem (long stacks, CLS, async exception handling,...) given the previous definitions.


We define the following module code that provides the needed explicit marking
of API's that are exposing asynchronous behavior from a `host` component to
- **causal** -- when the execution of a function _f_ in context _i_ is
Copy link
Owner

@mike-kaufman mike-kaufman Dec 20, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

for completeness here, do we want to define "execution context" as well?

@mike-kaufman mike-kaufman merged commit 832833b into mike-kaufman:master Jan 10, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants