Re: [lwip-users] Why does user code need to lock tcp core?
Hi Simon,
fair enough. Makes sense. Thx for the time to answer anyway!
Op do 17 jun. 2021 om 13:50 schreef Simon Goldschmidt :
>
>
> Am 17. Juni 2021 11:46:13 MESZ schrieb Bas Prins :
> >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(_netif);
> > ppp = pppos_create(_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(
> > ,
> > port,
> > "/513KB.zip",
> > ,
> > 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
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
Re: [lwip-users] Why does user code need to lock tcp core?
Am 17. Juni 2021 11:46:13 MESZ schrieb Bas Prins :
>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(_netif);
>ppp = pppos_create(_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(
>,
>port,
>"/513KB.zip",
>,
>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
[lwip-users] Why does user code need to lock tcp core?
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(_netif);
ppp = pppos_create(_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(
,
port,
"/513KB.zip",
,
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?
Best regards, bas
___
lwip-users mailing list
lwip-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/lwip-users
