The port I'm using is using 1.3.2 version, so I doubt there's this option
from the unreleased branch. I'll try to follow how select is implemented
and see if there's a non-blocking way to check if a packet has arived on a
socket/session so I don't block the thread indefinitely.
On Fri, Mar 18, 201
Well, I'm developing an application for Xen's MiniOS which is quite a large
project (kind of) and while making a fork of it and trying to port to 1.4.1
sounds tempting, it'd require me to dig some code (but would help me remove
the damned #ifdefs becuase I'm using on Linux 1.4.1).
I'm not using se
Hello, I'm developing an application that requires multiple clients to be
kept on separate threads (be it 1 client/thread or thread queue). Those
clients communicate between each other also by using the server application.
I'm using netconn API atm, but I can switch to raw api if that makes more
s
Pîrvu Mihai wrote:
The port I'm using is using 1.3.2 version
Yikes! There have really been many fixes since then!
I'll try to follow how select is implemented
Why don't you actually use select? However, there may be bugs in 1.3.2's
select...
Simon
Pîrvu Mihai wrote:
I've read that different threads cannot call the same socket/netconn
session at the same time, so I guess this is where my problem lays.
You can use the fairly new option LWIP_NETCONN_FULLDUPLEX set to 1,
which in combination with thread-local semaphores
(LWIP_NETCONN_SEM_P
