core: define default flags

[miri64]

#2711 (comment) revealed that it can be problematic starting a thread without CREATE_STACKTEST when trying to debug. #2758 (comment) suggested to create a macro for default flags (if there are more than CREATE_STACKTEST these can be added to).

[kaspar030]

For CREATE_STACKTEST, fix ps to show edit that the thread doesn't have that information.

All other flags have intrinsic defaults, e.g., CREATE_STACKTEST and CREATE_SLEEPING are opt-in, CREATE_WITHOUT_YIELD is opt-out. No need to waste code & flash for another place to store defaults.

[OlegHahm]

I don't get the proposal. @authmillenon, can you rephrase, please?

[miri64]

It was more or less @haukepetersen's idea and this was what I gathered from him. Maybe he can do that?

[kaspar030]

If I understand correctly, @haukepetersen wondered why it's pktpuf thread always showed the full stacksize when watched with ps. The problem was that the thread was not created with the CREATE_STACKTEST flag set, which he fixed by setting that flag.

Now @authmillenon proposed to introduce default thread creation flags, so that i.e., CREATE_STACKTEST can be switched on globally.

[LudwigKnuepfer]

I think this would be beneficial because one could save the cost of CREATE_STACKTEST in production environments.

[OlegHahm]

Sounds good.

[LudwigKnuepfer]

Maybe we can remove this from the flags altogether and just ifdef the section of the thread creation function? I can't really think of a situation where one would want to turn this off for individual threads only.

[LudwigKnuepfer]

This -> CREATESTACKTEST

[Kijewski]

Maybe we can remove this from the flags altogether and just ifdef the section of the thread creation function?

👍

[OlegHahm]

👍 @kaspar030, I guess you've initially implemented this. Was there a rationale behind that?

[kaspar030]

Well, CREATE_STACKTEST makes the thread creation write something to the entire stack. As that is time-consuming, there was no "ps" and it's O(n), I made it optional.

Also there might be (future) use-cases where this is not needed / too time-consuming:

• Using CREATE_STACKTEST for stacks created one at boot is fine, when creating them dynamically, it feels like way too much overhead. Imagine implementing signals as one-shot threads using a shared stack. No need to CREATE_STACKTEST
• Remember the discussion whether it should be possible to create a thread in ISR context? CREATE_STACKTEST as default is a no-go there.

Mind that this is only used by ps. But we could turn the flag around (CREATE_NOSTACKTEST) for the special use cases, and #ifdef out the code for "production" builds.

[OlegHahm]

The rationale provided by @kaspar030 seems sound to me. However,

For CREATE_STACKTEST, fix ps to show edit that the thread doesn't have that information.

is also not possible without storing the information somewhere in the tcb which is also definitely not desirable. Hence, I would tend to close this as wontfix. Any objections?

[kaspar030]

no :)

[LudwigKnuepfer]

Not going to work on this any time soon.

[kaspar030]

Ok to close this (maybe with memo flag)?

[miri64]

I'm fine. IIRC @haukepetersen was the one originally proposing the idea. What has he to say?

[kYc0o]

Is this still a known issue?

[miri64]

Why was it in the known issues anyway? This is a feature proposal, not a bug...