gustavonihei commented on code in PR #6197:
URL: https://github.com/apache/incubator-nuttx/pull/6197#discussion_r880691328
##########
arch/risc-v/src/esp32c3/esp32c3_wifi_adapter.c:
##########
@@ -1339,20 +1340,23 @@ static int IRAM_ATTR wifi_is_in_isr(void)
static void *esp_thread_semphr_get(void)
{
int ret;
- int i;
void *sem;
- struct tcb_s *tcb = this_task();
- struct task_group_s *group = tcb->group;
- for (i = 0; i < CONFIG_SCHED_EXIT_MAX; i++)
+ if (!g_wifi_tkey_init)
{
- if (group->tg_exit[i].func.on == esp_thread_semphr_free)
+ ret = tls_alloc(NULL);
+ if (ret < 0)
{
- break;
+ wlerr("Failed to create pthread key\n");
+ return NULL;
}
+
+ g_wifi_thread_key = ret;
+ g_wifi_tkey_init = true;
}
- if (i >= CONFIG_SCHED_EXIT_MAX)
+ sem = (void *)tls_get_value(g_wifi_thread_key);
Review Comment:
@pussuw @xiaoxiang781216 @pkarashchenko I think I understood the issue once
again. The Wi-Fi kernel thread creates a new semaphore for every new socket
connection (e.g. from `wapi`), but when allocating it on Thread-Local Storage
it fails to destroy the semaphores due to the threads creating the semaphores
belonging to a different Task Group from the one that originally created the
Pthread Key.
Refactoring the solution to use Task Local Storage worked and the semaphores
are now properly destroyed after `wapi` finishes.
The new solution for both ESP32 and ESP32-C3 is undergoing our internal CI.
I'll submit it as soon as it passes.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
