lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Why does user code need to lock tcp core?


From: Bas Prins
Subject: Re: [lwip-users] Why does user code need to lock tcp core?
Date: Thu, 17 Jun 2021 14:17:06 +0200

Hi Simon,

fair enough. Makes sense. Thx for the time to answer anyway!

Op do 17 jun. 2021 om 13:50 schreef Simon Goldschmidt <goldsimon@gmx.de>:


Am 17. Juni 2021 11:46:13 MESZ schrieb Bas Prins <bas.prins3@gmail.com>:
>Hi all,
>
>I just found out that my lwipopts.h was lacking quite a lot, which
>completely disabled the core locking assert. After fixing this, I did
>run
>into a few asserts. But all in places where I am not expecting them.
>
>Why do I need to lock for example:
>
> LOCK_TCPIP_CORE();
> netif_set_default(&pppos_netif);
> ppp = pppos_create(&pppos_netif, ppp_output_cb, ppp_link_status_cb,
>nullptr);
> if (!ppp)
> {
> logger.WriteDebug(LoggingCategoryPppClient,
>"Failed to create pppos client");
> return;
> }
> ppp_connect(ppp, 0);
> UNLOCK_TCPIP_CORE();
>
>or calls like this
>
> LOCK_TCPIP_CORE();
> err_t err = httpc_get_file(
> &ip,
> port,
> "/513KB.zip",
> &settings,
> rec_fn,
> nullptr,
> nullptr);
> UNLOCK_TCPIP_CORE();
>
>As far as I understand there I no need at all to make this a user code
>responsibility. The lwip functions could perfectly do this first hand
>*for
>me*.
>
>I can imagine a minor performance deal there. But if that's the
>argument,
>it could be made configurable, right? If the user of the library
>doesn't
>want to bother with these locks, at the cost of some unnecessary
>lock/unlocks, they could opt for that in the lwipopts.
>
>Would this be something that could be interesting to improve or am I
>missing something here?

The lwIP core code is currently written in a way that is not thread safe. Users have to ensure to use it in the correct way. The asserts help you to use it in the correct way.

Adding those locks to the code so that you don't need to care is not an easy task we could never know if the caller has already locked or not. Worse, some functions call other functions that are public, too, so that might lead to locking twice. And mutexes that allow such multiple locking (from a task that already owns the lock) are not easily available on every platform. Being like that, what you requested is currently not in the list of features to develop.

Regards,
Simon
_______________________________________________
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users

reply via email to

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