LockingTextWriter/Reader

[Steven Schveighoffer]

On Fri, 12 Oct 2012 13:06:16 -0400, Adam D. Ruppe  
<destructionator at gmail.com> wrote:

> std.stdio has a nice struct called LockingTextReader in the source. The  
> thing is it isn't documented at all, and I don't think it even does its  
> own interface.
>
> It claims to return dchars, but apparently reads bytes.
>
> Its counterpart, LockingTextWriter, seems to do a little more dchar  
> related stuff but again, I'm not sure what exactly it is supposed to do.

What they do is lock the FILE * while you use it, and they are  
input/output ranges.  So instead of acquiring a lock every time you call  
fwrite/fprintf, it locks once, and calls a special version of these that  
assumes the object is already locked.  This speeds up output tremendously,  
but still isn't as good as it could be with native D code.

 From what I remember, the non-UTF8 mode depends on C wide char support,  
which is severely lacking, and doesn't even work right on some platforms.

> What are these supposed to actually do? I tried doing a simple unix cat  
> like program:
>
> stdout.write(LockingTextReader(File("in"));
>
> and while it worked correctly on an ascii text file, it corrupted a  
> binary file. The name "Text" makes me think it isn't meant to work on a  
> binary file, but it'd be so useful if it did...

What platform?  On Windows, there is the whole issue of CRLF -> LF  
translation.

In my update to stdio (long overdue), I have support for reading/writing 5  
forms of UTF -- UTF8, UTF16, UTF16LE, UTF32, UTF32LE, along with binary  
read/write support using native D buffers, and avoiding locking altogether  
if your object isn't shared.

Note that C has very poor support for anything other than ASCII.  For  
instance, fwide on Windows is a noop (not DMC, but windows), and doesn't  
work correctly from what I tested on Linux.

-Steve