A cure for bad/long lasting user code calls

[vortigont]

Let's start another thread for this.

Sharing another way to consider on how to completely get rid of all the negative effects of long user (or any internal) calls.
IMO it's much better from the architecture point of view is to implement some dispatcher layer in the ESPAsyncServer itself. It should sit in the middle between user code and AsyncTCP's lower part, dispatch the data back and forth and do not let AsyncTCP task's callbacks to call user code directly.
It would need many features from RTOS so this is for no-8266 era.

P.S. I'm not familiar with psychic 's architecture, how does it behaves in similar workloads? Has it something similar under the hood?

[mathieucarbou]

Good question about psychic....

I thi k it would stall also the other requests but I can check.

Esp-idf has a configuration to define also the number or worker threads to they spawn as many async tasks to process requests to improve concurrency. Psychichttp uses that but spawning several tasks is really hungry. In the case of the long requests issue it would not solve it. I think to solve it we need a way to know that such request is slow and have a way to move it aside to not block other incoming ones.

Also the number of opened sockets is configurable but me-no-dev said in Discord that for Arduino Core this number is set to 16 and cannot be changed.
The only way to change the esp-idf param is to use the new hybrid compilation that will be available in pioarduino starting 3.1.0 release where we I'll be able to overwrite esp-idf config and components through some new platformio parameters.

[vortigont]

agreed, that might be hungry. On the other hand, asynctcp's task could have as small stack as possible and segregating it with user callbacks would make the network part very responsive. Separate "workers" could be spawned on demand for specific things like user-side chunked callbacks or template processing. It might need some heavy refactoring of server's internals. Just throwing ideas here for now.