LWIP capabilities

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

LWIP capabilities

Robert Morse
Hi,
        I am trying to use the lwip stack and while most things are working I
am having some
problems.

        I have a lot of connections that are needed.

        I have 1 thread that listens on a TCP port, then passes the connected
socket
off to 1 of 3 threads (These are static threads not created on the
fly).  They deal with
the transfer of data, the close the socket, then wait for a new one to
be passed to it.
These connections can be short <open><command><response><close> or they
can be chained
commands where you have
<open><command><response>..........<command><response><close> where
the connection might be open for a long period of time, the chained
command has a 300MS
timeout then the socket will be closed.

        I have 1 thread that listens on a UDP port, that accepts requests from
clients, and a
second thread sends status information out, to clients that have
subscribed.
This uses recvfrom, and sendto.

        At a later date, another 3 or 4 threads doing TCP/UDP will also need
to be added.

        It seems like everything is ok, as long as I only have one TCP
connection running, I
can sometimes get away with a second TCP connection, but other times
everything locks up.
I am currently not sure where the lock up is, as I don't have an
in-circuit debugger to
figure out where it is stopping.

        My driver, in the receive interrupt, just messages a HIGH priority
task, to actually
handle passing the data into the lwip stack.

So, my question is do you think I am pushing the lwip stack to far?

Robert



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: LWIP capabilities

Jonathan Larmour
Robert Morse wrote:

>     My driver, in the receive interrupt, just messages a HIGH priority
> task, to actually
> handle passing the data into the lwip stack.

How specifically does it do that? Does it call etharp_ip_input() directly
for example?

Although I can't see any immediate problem in what is in your description,
this sounds a lot like an inter-thread locking problem of some sort.

I assume you are using the sequential (netconn) API. The most obvious thing
to bear in mind is that the thread-safety is limited - you should only use
one connection in one thread at one time. You can't use the same connection
in two different threads at one time.

Jifl
--
eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
------["The best things in life aren't things."]------      Opinions==mine


_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users
Reply | Threaded
Open this post in threaded view
|

Re: LWIP capabilities

Robert Morse

On Apr 18, 2007, at 4:44 PM, Jonathan Larmour wrote:

> Robert Morse wrote:
>
>>     My driver, in the receive interrupt, just messages a HIGH
>> priority task, to actually
>> handle passing the data into the lwip stack.
>
> How specifically does it do that? Does it call etharp_ip_input()
> directly for example?
>

I have an task that waits for a message from the ethernet interrupt
handler.
It then does:

loop {
        sys_arch_mbox_fetch( handler_mbox, &dummy, 0 );
        while ( (pbuf = low_level_input()) != NULL )
        {
                switch( ethhdr->type )
                        case ETHTYPE_IP:
                                ....
                        case THETYPE_ARP:
                                etharp_arp_input(netif, addr, pbuf)
        }
}
I had this all done in the interrupt routine, but trying to protect the
memory allocation
for both interrupt and task, just did not seem like it was that
protective of each other.
So I created a task that did the creating of the pbufs.


> Although I can't see any immediate problem in what is in your
> description, this sounds a lot like an inter-thread locking problem of
> some sort.
>

Ya, that is what I think it is.

> I assume you are using the sequential (netconn) API. The most obvious
> thing to bear in mind is that the thread-safety is limited - you
> should only use one connection in one thread at one time. You can't
> use the same connection in two different threads at one time.
>

I am using the 'bsd' interface, socket, accept, send, recv. Which I
believe sit on top of the netconn layer.

The only place where two threads interact is I have a thread doing a
listen, which then passes the
return socket to another thread that does all the communications. So I
guess you would say that one
thread is doing an open, while another thread is doing everything else
up to the close.


Ok,
        This is what I wanted to hear. I will keep looking at where a possible
dead lock is happening.

Robert


> Jifl
> --
> eCosCentric Limited      http://www.eCosCentric.com/     The eCos
> experts
> Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223
> 245571
> Registered in England and Wales: Reg No 4422071.
> ------["The best things in life aren't things."]------      
> Opinions==mine
>
>
> _______________________________________________
> lwip-users mailing list
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/lwip-users
>



_______________________________________________
lwip-users mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/lwip-users