Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>It seems your problem is fundamental, and not related to C++. Other languages are perhaps better in hiding the stack usage, but as long as you haven't returned from Foo() you need the call stack for Foo(). And if you're also executing Bar(), that too needs a callstack. </p> <p>Threads are an excellent approach to this, as each thread comes with its own callstack. Continuations are a smart but complicated way to save callstacks, so where available those are an option too. But if you don't want those, you'll have to make do with one callstack. </p> <p>Daling with one callstack requires addressing reentrancy. Here, there's no generic answer on what's possible. In general, you will have a set of Messages M1..Mx which are handled by functions F1...Fy, with some application-specific and possibly state-dependent mapping. With a reentrant message loop, you might be executing Fi when you receive Mj. Now the problem is what to do. Not all functions F1...Fn may be callable; in particular Fi itself may not be callable. However, some other functions may also be unavailable, e.g. because they share resources. This is application-dependent. </p> <p>If the processing of Mj requires any of these unavailable functions, you have to postpone it. Can you accept the next message in the queue? Again, that's implemenation dependent, and it may even relate to the message type and content. If the messages are sufficiently independent, it's possible to execute them out of order. This quickly becomes rather complex - to determine whether it's possible to accept the Nth message in the queue, you have to check if it can be executed out-of-order with respect to the preceding N-1 messages.</p> <p>A language can help you by not hiding dependencies, but in the end you must make the explicit decisions. There's no silver bullet.</p>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload