Re: [lwip-devel] brain storming about "socket2"

[Jonathan Larmour]

Piero 74 wrote:
> 
> 
> 2009/1/9 Jonathan Larmour <address@hidden
> <mailto:address@hidden>>
> 
>     Piero 74 wrote:
>     > Hi all
>     >
>     > I proposed a discussion... a brain storming about new socket
>     > implementation for the future (fast and more compliance to bsd socket)
>     > We could start to gather ideas here and create a working group...
>     >
>     > Starting with an old email from Simon:
> 
>     Some work was even started on it. It's in task 6994, however that is a
>     private task. I'll leave it to Simon/Frederic to decide if they want to
>     open it up - the reason it was private was so that people didn't try to
>     start using something that was in its very early stages.
> 
>     On the other hand, rather than more compliance to BSD sockets, there was
>     discussion in that task (reflected in the sketched out
>     implementation) that
>     it would be ok to move further away from BSD/POSIX socket API
>     compliance,
>     which wasn't something I was keen on personally. But that was a
>     discussion
>     point in the task. The general idea of implementing sockets directly
>     over
>     the raw API is good though.
> 
> 
> J,
> I have a doubt...
> socket above netconn permits to have THREAD-SAFE socket...
> If socket2 will be implemented over raw API, will are thread-safe yet?
> Or, we could not use socket2 in multithread system (lwip+rtos)?

The intention was to use LWIP_TCPIP_CORE_LOCKING. That uses a semaphore to
control all access to the lwIP stack. Have a look for its existing use in
the current sources. As you'll see in opt.h, it's classed as experimental
though. It hasn't been well tested and there would probably be issues.

> Doing some performance test, i saw some time consuming calling recv
> function, i suppose for netconn call (which has to send a msg to
> lwip_thread and wait callback..)
> So, socket2 could be realy very fast??

If your OS has very slow message passing, then maybe. Most RTOS's are not
that slow when passing messages between threads. It would be faster, but I
don't think it would be that much faster as that's not where most of the
time is spent.

If you are trying to improve performance in the current code base, you may
be better off not using sockets, and using the netconn API instead (or
better still the raw API - albeit with more application changes). The
present sockets API is only really there as a way for people to port
existing code for less effort. It's not a great choice for writing
something new.

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.
------["Si fractum non sit, noli id reficere"]------       Opinions==mine