Pinning (std::)threads to cores
Posted: Sun Nov 04, 2018 4:34 pm
by permal
We can currently set the stack size for a
std::thread like this, thanks to the esp-additions to pthread and the fact that std::thread are built upon pthreads.
Code: Select all
esp_pthread_cfg_t worker_config{};
worker_config.stack_size = 1234;
worker_config.prio = 1234;
esp_pthread_set_cfg(&worker_config);
worker = std::thread([this]()
{
this->exec();
}
);
Is there a way to pin a
std::threads to a specific core without reverting back to
xTaskCreatePinnedToCore?
If not, could perhaps a core_id be added to the esp_pthread_cfg_t struct to accomplish it?
Re: Pinning (std::)threads to cores
Posted: Mon Nov 05, 2018 8:45 pm
by permal
A followup to the above; would it be possible to add the name of the task to the esp_pthread_cfg_t structure too? It'd be a ESP-specific feature, but it'd help greatly debugging this particular error message as there are numerous 'pthread' tasks:
***ERROR*** A stack overflow in task pthread has been detected.
Re: Pinning (std::)threads to cores
Posted: Tue Nov 06, 2018 10:17 pm
by ESP_Angus
Hi pemal,
I can see how this would be useful. Although it seems like it's a little fiddly to have to call this function before each new thread is created, I don't know of a better solution.
I've logged this as a feature request internally. We don't have an ETA at the moment for any implementation. (On the other hand, a PR on GitHub which added these features would probably be merged.)
BTW, for future reference, if you're looking to request a specific feature which definitely doesn't exist in ESP-IDF right now, the most convenient way (from perspective of our team's workflow) is to do this by opening a GitHub issue. Opening a thread here is fine too, but it can be easier for these to get lost over time.
Re: Pinning (std::)threads to cores
Posted: Wed Nov 07, 2018 11:56 am
by permal
Thanks for the feedback. I'll post these things on GitHub going forward.
In my framework I've got a
Task which does all the work for me. Without that it would get a bit fiddly, as you say. I wouldn't mind seeing an
idf::thread taking name, stack and priority as arguments, but that would introduce C++ into the IDF framework and I suppose you want to keep that all in C?