lwip-users
[Top][All Lists]
Advanced

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

Re: [lwip-users] Writing a proxy server - how "non-reentrant" is lwip ra


From: Peter Montgomery
Subject: Re: [lwip-users] Writing a proxy server - how "non-reentrant" is lwip raw API?
Date: Tue, 14 Jun 2011 23:07:43 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10

Leon,

Can I assume that I can call "tcp_write" from the mainline (not lwIP interrupt driven) code without problems? My app receives data TCP data using a ring buffer that the interrupt driven lwIP code fill, and which is read by mainline code. However, my mainline code does reply by directly calling "tcp_write." It all seems to work, but I was hoping for clarification.

        Thanks,
        PeterM

On 6/14/2011 6:36 PM, Leon Woestenberg wrote:
Hello,

On Wed, Jun 15, 2011 at 2:13 AM, wurzel<address@hidden>  wrote:

My question is, can I call tcp_write from within a tcp_recv
callback?  In this code, I've opened a pair of TCP pcbs and
each one's state struct has a "mate" field that points to
the other side's state struct to I can get its pcb.

I think that's a very good question indeed, because we give no
explicit guarantee in our documentation that this is guaranteed to
work, AFAIK. A function is called reentrant if it can be interrupted
and called again before previous calls complete execution. Now, as
there are global variables in the stack, we cannot easily guarantee
reentrancy, other than through code validation.

                        snderr = tcp_write(rs->mate->mypcb, q->payload, q->len, 
0);

By the strictest definition of "non-reentrant" this might not be
legal.  On the other hand, this seems like a commonly-desired case,
so I'm hoping it is expected to work?

Yes, this should work. The tcp transmit code paths are cleanly
seperated from the receive code paths through data structures. We
should assume at the callback point the tcp state machine has those
structures in valid state, valid enough to call into tcp_write().

Regards,



reply via email to

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