[lwip-devel] [task #6994] Redesign Socket Layer with LWIP_TCPIP_CORE_LOCKING

[Frédéric Bernon]

Follow-up Comment #2, task #6994 (project lwip):

>Why not include all functions in 'socket2.c'? We don't have to seperate the
code into 'application thread code' and 'tcpip_thread code' like with
api_lib/api_msg. Just lock the core and go on with the code... 

But there is still a part really near the raw api, like all the callbacks.
Because most could be similar to current api_msg.c, keeping the same name to
avoid to get a very large file is not a so bad idea. This choose is very
linked to RX part design (see next point)

>We wouldn't even need the tcpip_thread any more. Simply lock and call into
the core from your RX-thread (if it's not done in interrupt context). 

I don't think about a such design for the RX part. But when we will be at
this step, we could talk about that. Note that most OS have restricted call
in IT context. But, ok, we will study that if you want...

>Even timeouts can be done easier: Either in an extra thread or in the
RX-thread. Both version would remove the need for a per-thread timeout we
have now. That way, sys_sem_wait and sys_mbox_fetch get smaller, too.

If we except PPP, I even thing that the full sys_timeout can be replace by
something more optimized (without any memp calls). And if all timers are
handled vy tcpip_thread, so, yes, no need to get a per-thread timeouts list.

>In a further step I'd like to introduce finer graned locking so that e.g.
only tcp and its pcb is locked while processing a received tcp segment. This
could help prioritizing some connections over others.

Once we got something working and reliable with the global semaphore, yes,
this step will be a good idea!!!


    _______________________________________________________

Reply to this item at:

  <http://savannah.nongnu.org/task/?6994>

_______________________________________________
  Message posté via/par Savannah
  http://savannah.nongnu.org/