iopipe v0.2.0 - safe update

Steven Schveighoffer schveiguy at gmail.com
Tue Jun 30 12:15:54 UTC 2020


On 6/30/20 6:41 AM, Joseph Rushton Wakeling wrote:
> On Sunday, 28 June 2020 at 18:57:22 UTC, Steven Schveighoffer wrote:
>> Just wanted to post that I finished my update of iopipe to be @safe. I 
>> still have some work to do with std.io so things are more usable (next 
>> on my list is to make standard handles accessible).
> 
> Cool, and congratulations :-)
> 
>> Inside iopipe is a RefCounted type that is @safe. It uses the GC for 
>> memory management, so while destruction is synchronous, the memory 
>> itself is left to the GC to clean up.
> 
> One concern here -- this means that one cannot control when an app using 
> this might block for GC, right?  Any thoughts on how a user could get 
> more deterministic control on when the memory would be released?

Ref counting is only used internally when I need automatic cleanup. I 
should be able to make it possible to specify an alternate ref-counting 
scheme (i.e. allow using std.typecons.refCounted instead). Certainly, 
you don't need to use it for most things. The current places where it's 
automatically used are for output (in the case of auto-flush, if you 
don't want auto-flush, then it does not refcount the pipe), and in the 
zip/unzip pipes, which depend on zlib, and zlib uses some 
self-referencing pointers I think inside its struct.

It is already possible to use an alternative allocator for buffering.

-Steve


More information about the Digitalmars-d-announce mailing list