lwip-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lwip-users] Recommendations needed for API design


From: Kieran Mansley
Subject: Re: [lwip-users] Recommendations needed for API design
Date: Fri, 19 Feb 2010 14:39:13 +0000

On Fri, 2010-02-19 at 15:02 +0100, Marcus Bäckman wrote:
> Hello,
>  
> I am currently porting lwip for our ppc hardware, and have so far
> succesfully been using the raw TCP API. 
> The requirements for the application interface is a socket interface
> without the blocking functionality and I have some questions regarding
> its design.
>  
> The stack will be running in a mulithreaded environment with certain
> restrictions, for example: only one thread a time will use a certain
> socket at a time. 
> I would prefer not to have any dependency towards the operating
> system, and the approach is to make further restrictions on the
> application to guarantee safe multithreaded usage.

I'm a little confused about your use of the word socket.  It sounds like
you're trying to create an interface that is a cut down version of BSD
sockets.  We could really do with another term to describe your API to
avoid confusion.

> Here is my thoughts of the general approach:
> - Each socket has a dedicated area for buffering incoming pbuf's.

Sounds fine.

> - Transmission data will be queued and handled in a seperate thread
> which transmits pending data and processes incoming data.

It sounds rather like you'll pass transmit data to the existing
tcpip_thread to process, which is an excellent idea.  You must ensure
there is only one thread active in the stack at any one time.  The
easiest way to do this is to use the tcpip_thread provided for this
purpose, and have your new API pass packets to/from it rather than
trying to process them directly.  This is how the netconn API is built
(and the sockets API on top of that), so that would be a good example.

> What are your thoughts on this approach? Would it be easier you just 
> abandon it in favor for the current socket/netconn API ?

For your requirements, I think you'll have to make your own interface.
The current sockets and netconn APIs do not support the sort of
multithreaded access that you require.  You could probably use them by
having a mutex in your code for each socket to ensure only one thread at
time accesses them, but this is the sort of area where people often
encounter problems. 

> Is it multithread safe to use pbuf_free() on a pbufs (PBUF_RAW from
> PBUF_POOL) from one context, and in another context use pbuf_alloc()
> (PBUF_RAW)?

Yes, I think so.  pbufs are often allocated for received packets by an
interrupt handler and for sent packets by the tcpip_thread for example.

Kieran






reply via email to

[Prev in Thread] Current Thread [Next in Thread]