Re: [lwip-users] timeouts in multi-threaded implementation.

[David Haas]

Hi David,

I'll try to answer this.

If a particular thread never uses a lwip timer, then you are right, 
there is no reason to call sys_mbox_fetch and you could probably call 
sys_arch_mbox_fetch instead. Timers are set up on a per-thread basis. 
However, non of the API code knows whether or not the caller is going to 
use a timer. So it needs to call sys_mbox_fetch. I know that I do have 
code which calls the socket interface and does have timers. I think the 
assumption has to be that any thread could have timers.

So, I would not recommend changing this for general use. If you know 
that your application code does not set up a timer, then you can change 
the calls in your own code.

In answer to your second question, about memp, mem, & pbuf protection, 
most of this is already set up to use a lightweight protection mechanism 
without semaphores. All you have to do is define SYS_LIGHTWEIGHT_PROT. I 
think we were not using it in mem.c, but I would argue that real malloc 
and free operations are not "lightweight" anyway. I also think we should 
not be using PBUF_RAM pbufs which call mem_malloc in the tcp code. This 
is on the agenda to change sometime, but noone has gotten to it yet.

David Ryan wrote:

> Hi all..
>
> Something I touched on a while ago was the issue of timeouts in a 
> multi-threaded implementation.  Looking at the code there doesn't seem 
> to be a good reason to always call sys_mbox_fetch rather than 
> sys_arch_mbox_fetch... and similarly sys_sem_wait over sys_arch_sem_wait.
>
> For instance the main tcpip thread in an API based implementation 
> should easily be able to handle any of the main timeouts by calling 
> the sys_mbox_fetch as it does now.  Is it neccessary to call 
> sys_mbox_fetch on threads that are calling socket functions using 
> threads external to the application?  Before I change the calls in my 
> code, I'm curious to know if I'm missing something here?
>
> If these calls to sys_mbox_fetch in the api_lib.c code do not need to 
> call or handle timeouts I'd rather not have it call sys_mbox_fetch.
>
> The same applies to the mem.c, memp.c, and pbuf.c use of 
> sys_sem_wait.   I would rather they call sys_arch_sem_wait directly 
> than handle timeouts in areas of the code which I know can be handled 
> sufficiently by the tcpip thread.  Could these mutexes be replaced 
> with sys_arch_protect instead?
>
> Does this make sense, or does checking these timeouts take precendance 
> over everything else?
>
> Thanks,
> David.
>
>
>
>
>
>
>
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/lwip-users