Talk:Call stack

From Wikipedia, the free encyclopedia
Jump to: navigation, search

Structure / Separate Stack Frame page ?[edit]

The "Structure" section is pretty good and comprehensive, it might make sense to consider putting the "stack frame"-related stuff on a separate "Stack Frame" page, what do you guys think?

Here are some additional pointers to help improve the "Stack Frame" related article:

Citations[edit]

Section 5 on Inspection says "Taking regular-time samples of the call stack can be useful in profiling the performance of programs." This section is marked 'dubious' and that does not sound right to me. Below are some references to this technique:

Erikostermueller (talk) 02:23, 3 October 2016 (UTC)

Long story short, I think it's safe to remove that 'dubious' tag, and I think the references you gave above should be added to the section.
That 'dubious' apparently was added by John lindgren (talk · contribs) in 2011, I think, see diff. However, at this time the text was this:
Taking random-time samples of the call stack can be very useful in optimizing performance of programs. The reason is if a subroutine call instruction appears on the call stack for a certain fraction of execution time, its possible removal would save that much time.
John lindgren used the tag to mark the second sentence of this text, and he added a corresponding comment to the talk page, now archived. See Talk:Call stack/Archive 1#Perfomance analysis: call instruction vs. entire function call. The text (and that second sentence in particular) was rewritten in 2013 by an anonymous user, commenting "Fixed the bogus performance analysis logic". See diff. After that it was cleaned up and refactored to the version that is now in the article.
I am going to remove that tag. Perhaps you could find the time to work in the references you found?
Tea2min (talk) 09:02, 3 October 2016 (UTC)
Looks good to me, thanks. John lindgren (talk) 06:23, 17 February 2017 (UTC)

Functions of the call stack section[edit]

...One is that each task can have its own stack, and thus the subroutine can be reentrant, that is, can be active simultaneously for different tasks doing different things...

I don't really see the connection between each task having its own stack and reentrancy being possible. Reentrancy would be possible even in the case of a stack that is shared between multiple tasks (each task pushes its own stack frame onto the stack and voila one has reentrancy). Could be better written as

...One advantage of stacks is that they allow sub routines to be reentrant...

Another issue I saw is with this line:

...Another benefit is that recursion is automatically supported...

Again, recursion is merely a special case of re-entrance, so isn't this line a bit redundant?

Proposed merge with Stack-based memory allocation[edit]

Merge to main Call stack#Local data storage . Prev proposal Talk:Call_stack/Archive_1#Merger_proposal. Some parts may be merged to Stack (abstract data type). Widefox; talk 16:04, 8 October 2017 (UTC)

The previous discussion has three votes for not merging. (One agrees that it should not merge, confusing if you don't read carefully.) They are different things. Note, for one, that stack-based memory allocation does not require a stack. Some systems implement it using a linked list, though the logic is stack-like. More generally, as noted in the name, stack is an abstract data type. A call stack is one not so abstract implementation, and as noted above doesn't even need a physical stack. Gah4 (talk) 04:24, 9 October 2017 (UTC)