Can we talk about / document threading semantics / requirements in PsychicHttp?

[egnor]

I think everyone here knows that ESPAsyncWebServer (or at least its origin fork) is a disaster in terms of thread safety. PsychicHttp is reported to be much better, which is great! But it's important for users to understand threading semantics to be able to write safe code using it...

The README has similar notes as ESPAsyncWebServer does, without clarifying too much: "PsychicHttp is a fully asynchronous server and as such does not run on the loop thread. You should not use yield or delay or any function that uses them inside the callbacks."

It would be good (necessary, even) to know the following

• Q: What is the thread context user callbacks are invoked on?
  • I think: the HTTP server thread, which means if that thread touches any of the same data loop() does, it MUST USE SYNCHRONIZATION, which basically nobody is doing?
• Q: What threads can methods on various PsychicHttp type objects be called FROM?
  • The PsychicHttpServer object should ONLY be accessed from the setup() / loop() thread??
    • What if you want to access it from a request handler?? What's safe and what's not?
  • I think: The PsychicRequest object should ONLY be accessed from the request handler??
  • I think: Similarly with PsychicWebSocketClient, ONLY access it from the event handler??
  • But I also think: You can save the socket (an int) somewhere, and use getClient() later??
    • where is it safe to call getClient() from??
    • how long is it safe to use the PsychicWebSocketClient you get back from that??
• Q: What happens if you DO delay, or yield, or do long-running computation in a callback?
• Q: What happens if you're sending lots of data, and the receiver is being slow (or goes offline entirely)?
  • Does this just stuff up the server thread indefinitely until some timeout??
• Q: What happens if a client dribbles out the request headers and stuff?
  • Again, does this just stuff up the server thread indefinitely??

[hoeken]

These are excellent questions, and unfortunately I don't have answers for them. The webserver does run in its own thread, as do the callbacks. If you need to do processing outside of callbacks, then you definitely need some threadsafe stuff. I explained how I'm doing that in my other project yarrboard or you can dig in to the code to see how its working.

• Accessing the server from a callback shouldn't be an issue unless you are using it in your loop. Then you might need to use semaphores or something. Most people setup the server in setup() then never touch it.
• PsychicRequest only lives for the duration of the callback. If you need to use it outside of that you need to store the data using queues (see: yarrboard)
• Technically, there probably is a safer way to access clients outside the callback, but the sockfd id is the id from the underlying socket library and there are quite a few checks surrounding that when you call getClient(). So far its working without issues to use it, but YMMV. I mostly use it to send messages to websocket clients asyncronously.
• That is why its important to save the sockfd, call getClient(), check if its valid, then send data. The server internally keeps track of all connected clients and if there's an unexpected disconnect, then that will catch it.

I can't remember what happens if you delay or yield too long inside a callback, but I think it just blocks processing. The server is async in its own thread, but it can only process one request at a time (at least until we get the async workers stuff fully tested)

Those last 2 questions are very interesting. There are definitely timeouts on the TCP connections, but I don't know what they are set to. There are quite a few configuration options in the esp-idf http server library that does the gruntwork, which is exposed as the server.config object.

#define HTTPD_DEFAULT_CONFIG() {                        \
        .task_priority      = tskIDLE_PRIORITY+5,       \
        .stack_size         = 4096,                     \
        .core_id            = tskNO_AFFINITY,           \
        .task_caps          = (MALLOC_CAP_INTERNAL | MALLOC_CAP_8BIT),       \
        .server_port        = 80,                       \
        .ctrl_port          = ESP_HTTPD_DEF_CTRL_PORT,  \
        .max_open_sockets   = 7,                        \
        .max_uri_handlers   = 8,                        \
        .max_resp_headers   = 8,                        \
        .backlog_conn       = 5,                        \
        .lru_purge_enable   = false,                    \
        .recv_wait_timeout  = 5,                        \
        .send_wait_timeout  = 5,                        \
        .global_user_ctx = NULL,                        \
        .global_user_ctx_free_fn = NULL,                \
        .global_transport_ctx = NULL,                   \
        .global_transport_ctx_free_fn = NULL,           \
        .enable_so_linger = false,                      \
        .linger_timeout = 0,                            \
        .keep_alive_enable = false,                     \
        .keep_alive_idle = 0,                           \
        .keep_alive_interval = 0,                       \
        .keep_alive_count = 0,                          \
        .open_fn = NULL,                                \
        .close_fn = NULL,                               \
        .uri_match_fn = NULL                            \
}

I'm moving this to discussions. If there are specific things you want to address, or have a PR for better documentation please feel free to resubmit.

[egnor]

(Thanks for the thoughtful response! And I didn't notice that discussions were on, this is definitely a discussion more than an issue. Will reply on other aspects when I have more cycles.)