Re: [lwip-users] lwIP RAW API and "deferred processing" indifferentcontext

[Ueli Niederer]

Quoting Gisle Vanem <address@hidden>:
> "Simon Goldschmidt" <address@hidden> wrote:
> > The big downside of that would however be that blocking socket  
> > calls wouldn't really make sense and thus, socket programming would  
> > be rather special (compared to how you normally write socket  
> > programs, i.e. sequential in a separate thread).
> I would think using non-blocking sockets (espesially in servers) would be
> more effective compared to spawning a separate thread for each connection.
Well, in fact the typical paradigm is to use a pool of pre-created  
threads instead of spawning one for each connection and let it die  
after the connection has been handled. If you use sort of non-blocking  
I/O you are forced to use state machines for the whole processing of  
the socket I/O to replace the sequencing done by the blocking API. You  
are also not able to timeslice the socket I/O in a easy way anymore.  
If you have one thread per socket and each thread with the same  
priority on a system that supports sort of round-robin scheduling, you  
have the chance to handle the socket in time sliced manner without any  
special measures.
In non-blocking I/O handling all the stuff in the same thread you  
_have to_ take special measures to achieve timeslicing in socket I/O.  
So you don't end up using all available buffer space for just one  
connection causing the others to be stalled.

But you are right: a framework on top the raw API giving some safer  
API and easier application development would be nice. I'm already  
thinking about how we chould add a "NO_SYS" api (or framework) that  
allows easy TCP application development with less pits, traps and  
mines...