lwip-devel
[Top][All Lists]
Advanced

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

[lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY


From: Jared Grubb
Subject: [lwip-devel] [task #6735] Provide new pbuf type: PBUF_RAM_NOCOPY
Date: Tue, 31 Jul 2007 17:41:54 +0000
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5

Follow-up Comment #12, task #6735 (project lwip):

> If you think the driver will be transmitting that fast, you could always
instead ensure the driver doesn't return until it is sent. 

You could do that, but there's no reason to stall the program waiting for
this to happen. In a driver, you can immediately return from the linkoutput,
but stall any other linkoutputs (via semaphore) until the previous is
finished.

Suppose you do give the user two valid ways of sending a packet: 

// Method A
p = pbuf_alloc(PBUF_RAM, ...);
fill_p_with_data(p);
some_output(p);
pbuf_free(p);

// Method B
p = pbuf_alloc(PBUF_RAM_NOCOPY, ...);
fill_p_with_data(p);
some_output(p); 

This makes it easy to make a critical mistake. If you do A but forget the
free, or you do B and add a free, then you have a major error in your
application. A nasty side effect is that it's not obvious from looking at the
code that you even made a mistake.

By requiring an application to always free a pbuf that it itself allocs (or
that it gets on return from the stack), you can see runtime errors in the code
itself. Even better: the application programmer only has to remember that
simple rule.

    _______________________________________________________

Reply to this item at:

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

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/





reply via email to

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