Introduce AFATFS_ASYNC_IO #2
Conversation
|
My concern with this approach is that if the sdcard read/write primitives are implemented synchronously (i.e. they call the completion callback before returning), this will cause asyncfatfs to re-enter afatfs_poll(). This will lead to it performing an unbounded amount of work (particularly at card init when writing the freefile) and using an unbounded amount of stacksize, neither of which can be tolerated. Synchronous read/write SD card primitives are a common choice when DMA is not available. |
Yes, I understand your concern. I had some thoughts about putting |
Risca
force-pushed
the
no_poll
branch
2 times, most recently
from
0604ce0 to
55a20a9
Compare
|
I reworked the changes so the feature can be enabled at compile time, and also updated the readme file 😺 @thenickdude, do you think this feature is useful for AsyncFS? |
This change introduces a new feature which enables afatfs_poll() to become an internal static function, and everything else works (almost) as before. The one difference is that callbacks may be called directly from the routine where it was provided, even before the routine returns. E.g. the callback for "unlink complete" may be called before afatfs_funlink() returns. The feature can be enabled by compiling AsyncFatFS with AFATFS_ASYNC_IO defined.
This change introduces a new feature which enables
afatfs_poll()to become an internal static function, and everything else works (almost) as before. The one difference is that callbacks may be called directly from the routine where it was provided, even before the routine returns. E.g. the callback for "unlink complete" may be called beforeafatfs_funlink()returns.The feature can be enabled by compiling AsyncFatFS with "AFATFS_ASYNC_IO" defined.