You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As @bIgBV points out elsewhere, to some degree we're dependent on hyper here, though its low-level APIs potentially give more flexibility.
A couple questions to consider:
Where should endpoint code run? Should we set up a thread pool and spawn endpoint code there always? Make that optional?
For the parts of the server that aren't tied directly to endpoints -- i.e., routing, middleware, etc -- do we want to require those pieces to be threadsafe and permit a muli-threaded implementation?
We should also consider the usecase of handling async tasks. Not in the futures sense, but in a business logic sense. Things like report generation jobs, notification jobs, or some other application specific task performed at a later time.
Plus, another thing to consider is how to handle synchronous tasks as a part of the business logic? Things like database accesses right now are synchronous in nature. The general idea seems to be spawning your own thread pool and running synchronous jobs on them, but can we consider providing built in support for that in Tide?
It's been a while since this issue was opened. Task generation is now handled by the underlying engine; all Tide does is provide the appropriate callback to it.
Based on the discussion in #48 I'm creating this issue to discuss the general threading model in Tide.
The text was updated successfully, but these errors were encountered: