Usually, the sys_timeout call places the handler in queue that is
specific to the task from which sys_timeout was called. Subsequent
calls to sys_mbox_fetch and sys_sem_wait in that same task context will
check the queue.
I started that with "usually", because the timeout queue used by a
given call to sys_timeout is determined by sys_arch_timeouts. That
makes it port specific, but segregating timeouts by task is generally a
good idea. The timeout code often touches resources unguarded by
mutexes. In such instances, it's important to keep the code running in
the context of the task that "owns" the resources. DHCP, for instance,
manipulates its database from within the tcpip task context, so it's
probably a good idea to run its timers in that context, as well.
The call you mentioned below should work fine from within the tcpip
task context, e.g. in tcpip_init_done, then subsequently from the
timeout handler itself.
Eric Shufro wrote:
Does this piece of code actually result in the calling of a timer, or is it
just for informational services to lwip?
sys_timeout(DHCP_FINE_TIMER_MSECS,
(sys_timeout_handler)dhcp_fine_timer, NULL);
I traced through it and don't see any place where it actually causes a
timeout via semaphore or system timeout (like ucos-ii's ostimedly()).
How does this work, and how should the timers actually be called, and what
other calls are involved.
Currently I am just outright calling the timers since the above code seems
to have no timeout and function call effect.
Thanks.
--eric
_______________________________________________
lwip-users mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/lwip-users
--
E-mail signature
Jim Gibbons
|
address@hidden
|
Gibbons and Associates, Inc.
|
TEL: (408) 984-1441
|
900 Lafayette, Suite 704, Santa Clara, CA
|
FAX: (408) 247-6395
|
|