Discussion about allocating memory from within an irq
So I've been thinkng about this, and I think it would be possible to have some type of scratch allocator which could be used inside interrupt handlers.
The actual scratch buffer would be allocated outside of the interrupt and somehow associated with the handler.
When the handler runs it would put the registered handler on top of a list of allocators. When a memory allocation is required, it would either use the scratch allocator, or if none were present, use the heap allocator. The scrath allocator would basically just increment a pointer by the number of bytes being allocated, as long as that number of bytes still exists in the scratch buffer,
Each time the interrupt fires, it would reset the scratch buffer.
I just thought I'd throw this out as an idea.
Clarify whether ubluetooth.BLE.irq handler is really an _interrupt_ handler
I’m currently tinkering around with the BLE support (I’m using the ESP32 IDF3 build of 1.13, fwiw) and noticed that some of the examples allocate memory etc. in the callback function passed to irq().
So, apparently the ISR rules don’t apply here, or at least not fully.
I know that the module is still experimental, but in order to do meaningful experiments with it, one has to know to some degree on what should be possible. 😉 Could you please clarify (ideally in the docs):
- whether, or to what degree, this callback is supposed to behave like an ISR
- which rules and best practices would apply when working with it and
- whether it’s important to return ASAP from the handler, in order to e.g. not miss scan results – or are they buffered somehow?
If the ISR rules largely or fully don’t apply to the handler function at all, considering to rename the irq function would be a good idea imho, because the name “IRQ” comes with some assumptions.