3 ms·
An example of this would be a pull parser for XML, right? A callback-based API can be built on top of the pull-based one if desired, but not the other way aroun
by ptx 5y ago
An example of this would be a pull parser for XML, right? A callback-based API can be built on top of the pull-based one if desired, but not the other way around, as far as I can tell, without using a separate thread. So the pull-based approach (i.e. putting stuff in a buffer) is more flexible.
But the issues you point out around callbacks and passing context parameters apply mostly to C. In languages that support closures it's easy to give callbacks whatever context they need.
- jstimpfle 5y agoYou could make a callback that only pushes to a buffer for later processing - to achieve the same behaviour that I suggested. So in a way, callbacks are more general (for an event that was pushed to a buffer, you can't have it be immediately processed by the other party, unless you add major threading and scheduling hackery). Nevertheless I recommend to never make a callback based API unless there is a clear need for callbacks. If there isn't a need, plain buffers (Maybe I should better say "queues") and decoupled processing are the right thing. Callbacks encourage synchronous processing and where they are used to only push to a buffer they are only overhead.