3 ms·
> A function call can't simply "not return" Remember "callback hell"? Assumption that a function call returns after running to completion requires rather speci
by friendzis 2y ago
> A function call can't simply "not return"
Remember "callback hell"? Assumption that a function call returns after running to completion requires rather specific synchronous cascading architecture, which WILL break in multithreaded code. Most of the multithreaded function calls will set a flag in shared memory and return early, expecting caller to poll.
If your API is based on single entry-point `invokeMethod(callee, method)` it is equally untraceable to event entry point `fireEvent(producer, event)`.
- lmm 2y ago> Most of the multithreaded function calls will set a flag in shared memory and return early, expecting caller to poll. Which is exactly switching from function calls to event-driven architecture, and the problems with that are exactly the problems we're talking about.
- friendzis 2y agoThe problems you describe are inherent to indirect invocations and are related to event-driven architectures only because typical event dispatching architecture is built on non-blocking calls. You do not even need return-early (non-blocking) semantics for these problems to manifest. You can implement a giant string-keyed vtable for all methods in your program (or use a language with advanced reflection capabilities) and will have exactly the same problems. Namely there probably won't be tooling to match caller-callee pairs, which is the core issue here.