Hotfix release vibe.d 0.7.28
ZombineDev via Digitalmars-d-announce
digitalmars-d-announce at puremagic.com
Mon Feb 29 02:20:01 PST 2016
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.
More information about the Digitalmars-d-announce
mailing list