[Top][All Lists]

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

[lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt cont

From: Jonathan Larmour
Subject: [lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe
Date: Fri, 28 Mar 2008 09:19:05 +0000
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.13) Gecko/20060513 Fedora/1.0.8-1.1.fc3.1.legacy Firefox/1.0.8

Follow-up Comment #17, bug #21433 (project lwip):

>> I'm slightly unsure about referring to disabling interrupts all the time
> You're right on that. 

Ok, instead of disabling "interrupts" maybe we could just refer to "other
context", so e.g. the option would be LWIP_USE_HEAP_FROM_OTHER_CONTEXT. Only a
suggestion mind.

> I created pbuf_free_callback() and mem_free_callback()

Yes I like the callback functions.

>> [comment #10]...
> Honestly, I'm not sure I completely understand your idea: You
> want to unprotect mem_MALLOC (your comment said mem_free)

Sorry yes my mistake (although mem_free changes too).

> during the search for a free block and restart the search if a
> free comes between that? That would make mem_malloc slower
> every time only because few times, mem_free could be called!
> Personally, I think that would be bad design (making the common
> case slower to be able to cope with an uncommon case)...

For the case of what you're trying to solve
(LWIP_USE_HEAP_FROM_INTERRUPT/OTHER_CONTEXT==1), it would greatly reduce the
interrupt latency (or the time the kernel task-switching is locked). In the
code at present, the latency increase is a far worse problem than the overall
run time in this case.

For the common case of LWIP_USE_HEAP_FROM_INTERRUPT/OTHER_CONTEXT==0 we can
still make this modified behaviour be controlled by a #if on this option, so
the previous (1.3.0 and older) behaviour is unmodified.


Reply to this item at:


  Message sent via/by Savannah

reply via email to

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