Sönke Ludwig
Sönke Ludwig
The load factor doesn't necessarily depend on the number of fibers itself, primarily it can become an issue for memory usage. Maybe a better heuristic is the number of enqueued...
The approach used by node-toobusy of measuring event loop latency also sounds interesting and would work exactly like that for vibe.d.
I'd like to make this a separate package ("vibe-overload"?) if possible. It may need some additional hooks, but it looks like it can be nicely self-contained. The main reason is...
I think nothing speaks against using multiple limits.
It will be enabled by default. It used to have side effects when it was an experimental feature, but nowadays it doesn't hurt as long as distributed TCP listening or...
There have been two major changes to the HTTP client between those versions - fixing the handling of keep-alive connections and sending `"application/json; charset=UTF-8"` instead of just `"application/json"`. Could any...
Looks like this may have to do with the version of eventcore (or vibe-core). Did you upgrade those together with vibe-d? Would be interesting to upgrade separately in that case...
What I wonder about the chosen representation is if `@optional!Out` actually makes sense in practice, since it would not be possible in general to deserialize serialized data in that case,...
> I like the idea and I think we should also provide the according @ignore!In, @ignore!Out. SImilarly, only `@ignore!In` and `@ignore!InOut` really make sense.
So what would be the use case for `@optional!Out`?