Right now, there are 3 request-response scenarios:
The user defines a request to be handled by returning an interpolated string. This kind of request can be handled by performing the interpolation logic on the Container's calling thread (one of Simple's 8 servicing threads), as it is not long-running or potentially blocking.
The user defines a request to be handled by an asynchronous response. This includes broadcast-subscribe and every() and after(). These requests are blocking or long-running, and need to be handled using a separate new thread, or some other process that offloads the processing from the Container's calling thread.
The user defines a custom handler to handle the request. The user could do anything in this handler.
Currently, scenario 3 is treated as though it were like scenario 1. But it's not. The user could perform potentially long-running, or blocking, tasks in the handler. The handler logic should not be performed on the Container's calling thread.
Right now, there are 3 request-response scenarios:
Currently, scenario 3 is treated as though it were like scenario 1. But it's not. The user could perform potentially long-running, or blocking, tasks in the handler. The handler logic should not be performed on the Container's calling thread.