Fabian Koch wrote:
> Big Fat Warning! This is not how it works! You are cleary violating
> threading rules here!!! Don't ever access the pcb from a different
> thread than the tcpip_thread or you will get random results!
This poses some more questions...
Until now I used:
conn->pcb.tcp->state : to print the state of my connections
conn->pcb.ip->ttl : as a replacement of SOCKET_SO_IP_TTL
conn->pcb.tcp->keep_idle: as a replacement of SOCKET_SO_KEEPALIVE
I think the first one I got from this list because I asked for a way
to get the TCP state.
The other two I use because I don't use the socket-API and have
disabled it but still need to present a set_sock_opt sort of fuction
to the outside.
Any ideas how I can make that work (even though it all worked until now)?
This is a basic multithreading question: variables that are read using
an atomic instruction are 'relatively' safe to read from another thread
(since the are always correct, only you don't know at which point you
read: they can be changed from the other thread at any time). However,
if you read an U32 on a 16-bit platform, you are likely to get garbage
if the thread is interrupted between the 2 read instructions necessary
to read 32 bit.
The variables you read/write from the wrong thread are relatively
static, so no wonder it works for you. However, the correct way to do it
is to use tcpip_callback() to get a user-specific function called in the
tcpip_thread(), where you are free to do with the pcb whatever you like :-)
Like I said, I'd be willing to send patches to get accepted so that I
can use a vanilla release some day.
No patches necessary there. What else are you missing to use lwIP as is?
*BTW: could you please respond in ASCII, not HTML? The font in your responses
is very small sometimes!*
Simon
_______________________________________________
lwip-users mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/lwip-users
