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
- Implements multi-isolate support for `RelicServer` to enable
concurrent request handling across multiple CPU cores.
- Refactors `RelicServer` into a sealed interface with the existing
implementation moved to `_RelicServer`.
- Adds `IsolatedObject<T>`, a generic wrapper that spawns an object in a
separate isolate and communicates via message passing.
- Introduces `_IsolatedRelicServer` and `_MultiIsolateRelicServer`
implementations of `RelicServer`.
- Adds `noOfIsolates` optional named parameter to `RelicServer`
constructor (which is now a factory, delegating to either _RelicServer
or _MultiIsolateRelicServer), and `RelicApp.run`.
This seems more complex, why the added complexity? The problem is that not everything follows the request response model. Today we have web-sockets, server-side events, etc. that hijacks the underlying socket of a request, and hands lifetime handling to the developer.
34
34
35
-
Shelf does support hijacking, but it does so by using exceptions for control flow. It will throw an exception `HijackException` that is only supposed to be caught and handled by a Shelf adaptor.
35
+
Shelf does support hijacking, but it does so by using exceptions for control flow. It will throw an exception `HijackException` that is only supposed to be caught and handled by a Shelf adapter.
36
36
37
37
As we consider using exceptions for control flow an anti-pattern, we have opted for introducing a `RequestContext` and an associated state machine instead.
0 commit comments