[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt cont
[lwip-devel] [bug #21433] Calling mem_free/pbuf_free from interrupt context isn't safe
Thu, 01 Nov 2007 13:01:21 +0000
Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:220.127.116.11) Gecko/20071008 Firefox/18.104.22.168
Follow-up Comment #12, bug #21433 (project lwip):
> plug_holes isn't a problem
Of course it's not, since there is no loop in it!
> I have to admit I'm a bit uneasy about increasing the amount of > stuff
that we support from interrupt [->bad code]
> I would have guessed (possibly wrongly) that most ethernet
> driver systems do operate at thread level because the amount
> of processing
For RX, I agree; for TX enqueuing also. But freeing ref'ed pbufs when they
are actually sent can be done quite fast in interrupt context, I think
(nothing to be copied), and I don't see bad coding here.
> [if] SYS_ARCH_PROTECT is OK then that would be a relatively
> simple change I think.
If it's configurable it would be OK with me but in general it leads to very
long periods of time where the interrupts are disabled (which _is_ bad code to
me; after all it's nearly the same as a very long running ISR). But since this
seems the only nice solution for both NO_SYS settings, I'm OK with it as long
a) using semaphore is the default
b) saying 'pbuf_free is not supported from interrupt level' is our default
c) pointing users to documentation that explicitly tells them to enable the
SYS_ARCH in mem.c so that they can use pbuf_free from interrupt context
> Either way, I think this is best left till after 1.3.0
> otherwise we'll never get it out.
But then again, maybe using tcpip_callback isn't so bad after all? :-)
But honestly: we can just introduce an option to use SYS_ARCH_PROTECT, that's
easily done before 1.3.0!
Reply to this item at:
Nachricht geschickt von/durch Savannah