Hotfix release vibe.d 0.7.28

[ZombineDev via Digitalmars-d-announce]

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.