[Top][All Lists]

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

Re: [lwip-users] Could sys_restart_timeouts be provided also for !NO_SYS

From: Ari Suutari
Subject: Re: [lwip-users] Could sys_restart_timeouts be provided also for !NO_SYS targets ?
Date: Mon, 26 Sep 2016 21:34:42 +0300


In my case sys_timeouts_mbox_fetch is not running when 
system sleeps. I have a function tcpipSuspend() which waits for
RTOS semaphore for tcp/ip stack to wake up. This function is
called with tcpip_callback_with_block, which makes the lwip stack
to “sleep” inside tcpip thread.

My project is  open source, see

Code has currently a kludgery workaround, it forcefully resets RTOS
‘jiffies’ after sleep, which is used by sys_now(), system works very well
with this.

I’ll enable sys_restart_timeouts and see if it works also, I think it should
because the effect should be same as my workaround.

    Ari S.

On 26 Sep 2016, at 21:20 , Sylvain Rochet <address@hidden> wrote:

Hi Ari,

On Mon, Sep 26, 2016 at 02:13:10PM +0300, Ari Suutari wrote:

This related to http://savannah.nongnu.org/bugs/index.php?48568

I have a system which sleeps long times but sys_now() progresses during
Currently this still seems to cause some surprises with timers.

While there seems to be discussion about moving to absolute time
in timers instead of current implementation, could it be possible that
timeouts.c provided
sys_restart_timeouts() function also for targets that are using RTOS in the
meantime ?

The problem here is that sys_timeouts_mbox_fetch() is still running when
you go to sleep, therefore calling sys_restart_timeouts() would do
nothing, this is why this function is currently not available in !NO_SYS

Anyway, could you try enabling sys_restart_timeouts() for !NO_SYS and
then calling it with tcpip_callback() to see what happen ? Theoretically
it should work but I'm not confident enough to certainly state there is
no corner case doing so.

(And yes, absolute timers does not have this problem ;)

lwip-users mailing list

reply via email to

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