On Monday, 29 February 2016 at 07:54:09 UTC, Sönke Ludwig wrote:
Am 29.02.2016 um 00:47 schrieb sigod:
On Saturday, 27 February 2016 at 16:21:05 UTC, Sönke Ludwig
wrote:
This is a small bugfix release that mainly fixes two critical
regressions:
- FreeListRef!T, which is used heavily in the HTTP server
code, stored
its reference count in an unallocated memory region,
leading to
possible memory leaks or memory corruption
- A TCP connection with a non-empty write buffer that got
closed by
the remote peer and locally at the same time could result
in the
calling task to starve (i.e. it got never resumed after
yielding
execution). In particular, this could happen when
accessing HTTPS
servers with the HTTP client in conjunction with
"Connection: close".
http://vibed.org/blog/posts/vibe-release-0.7.28
You forgot to update site header.
Thanks, also forgot the documentation (even if nothing has
changed).
Is there any plans on when big split will happen?
It will be a step-by-step process. I'm currently working on a
new version of the `vibe.core` package that contains some large
changes under the hood. Once that is in a functional state,
I'll look into how to enable optional replacement of the
existing vibe:core package by this new, separately hosted
vibe-core package. vibe:core, at that point, will only receive
bug fixes and continues to live for a while (let's say a year
or one and a half).
The same procedure will then happen for vibe:http (the new
package will include HTTP/2 support) and the other sub packages.
All of the new packages will get a version number of 1.0.0,
once they can be considered reasonably stable.
One unfortunate aspect of my current work on vibe-core is that
I'm building on a new event loop abstraction that I built as a
prototype to see where the performance bottlenecks of the
current system are. libasync was too slow and it had a too
complicated structure to make quick tests for improving
performance. Now I'm leaning towards finalizing the new
prototype library and proposing it for Phobos inclusion at some
point.
Hi Sonke,
I'm really interested in your work on a new event loop
abstraction. One of the big issues for the project I'm working on
is that the current implementation is not
@nogc and nothrow (while most of my code that doesn't interact
with vibe.d is nothrow, @nogc and where possible pure).
Another thing that I would like to request is support for
std.experimental.allocator. I need to be able to provide an
allocator through which all vibe-core allocations should happen.
Just to clarify, I'm only interested in having a @nogc/nothrow
event loop, as my project is a rather low-level (it is meant to
be used both from C and D code) and I won't need the other parts
of the framework (like web, db, etc.). And I think it's OK to use
the GC for application-level logic.
