[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[lwip-devel] [patch #9534] freertos: misc fixes, core locking check supp

From: Douglas
Subject: [lwip-devel] [patch #9534] freertos: misc fixes, core locking check support.
Date: Sat, 6 Jan 2018 01:13:33 -0500 (EST)
User-agent: Mozilla/5.0 (X11; Fedora; Linux x86_64; rv:57.0) Gecko/20100101 Firefox/57.0

Follow-up Comment #3, patch #9534 (project lwip):

> Next, why should we retry sys_mutex_lock etc. after a timeout? I don't
expect such a timeout to happen when passing portMAX_DELAY, or is there
something I am missing? 

Looking at the source code it appears that xQueueSemaphoreTake and
xQueueGenericSend can only return pdPASS when given portMAX_DELAY when
INCLUDE_vTaskSuspend == 1 (which is the case for esp-open-rtos), but might
some use of FreeRTOS not use INCLUDE_vTaskSuspend == 1 and actually time out
in which case the caller retrying seems appropriate. In any case there does
not appear to be an error return value to report.

> Moving sys_jiffies to sys_arch.h doesn't work though: FreeRTOS headers are
deliberately not exported via sys_arch.h in my port. 

Interesting so does that explain why there are 'struct _sys_mut' etc - was
wondering if esp-open-rtos should follow that approach?


Reply to this item at:


  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]