3

It is stated that you stack reallocation can happen. I don't understand this. I thought the whole point of setjmp/longjmp was to save the stack, and that it would be valid when longjmp'ing back. The comment seems to suggest the whole stack could be moved. This would offset all pointers, so I see why it should be avoided. But when does stack reallocation happen? I never heard this term before.

Janus Troelsen
  • 20,267
  • 14
  • 135
  • 196
  • Note that this comment is from the source code of `libconcurrency`, which implements coroutines, apparently by messing with the stack. –  Feb 14 '15 at 20:37
  • It's library-specific. Most likely internal restriction, as prohibiting address taking from automatic variables globally would be a new word in C programming. – Valeri Atamaniouk Feb 14 '15 at 20:38
  • @delnan They're probably even talking about their coroutine's stack, not *the* call stack. – dyp Feb 14 '15 at 20:40
  • [`coro_poll`](https://code.google.com/p/libconcurrency/source/browse/trunk/libconcurrency/coro.c#231) seems to grow/reallocate the *coroutine* stack if necessary. – dyp Feb 14 '15 at 20:43
  • With reference changing the offsets for the pointers - I don't think this will be the case - for that to happen your code would have to be relocated. From my understanding moving the stack buffer - would not really affect any function pointers etc pushed onto it - as I'm assuming the whole stack dump would move. I'm sure I'll get told otherwise if this isn't the case :-) - thanks, Neil – Neil Jun 25 '15 at 13:49

1 Answers1

1

It seems that comment about stack reallocation only applies to a coro stack, and not the general C stack

One would not generally pass the general C stack to a function, only an implementation of your own as follows:

 /*
  * Create a new coroutine from the given function, and with the
  * given stack.
  */
 EXPORT
 extern coro coro_new(_entry fn);

So, setjmp/longjmp would be as safe to use as always.

Glenn Teitelbaum
  • 10,108
  • 3
  • 36
  • 80