From 31b87d3d695e35c1daf1c88d2b5d6ddebec3e62b Mon Sep 17 00:00:00 2001 From: Boris Kolpackov Date: Wed, 3 Aug 2016 09:01:56 +0200 Subject: Implement faster emulation of Windows NUL via temporary file --- butl/fdstream | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) (limited to 'butl/fdstream') diff --git a/butl/fdstream b/butl/fdstream index 0caac5c..71de6a0 100644 --- a/butl/fdstream +++ b/butl/fdstream @@ -414,8 +414,26 @@ namespace butl // Note that it's the caller's responsibility to close the returned file // descriptor. // + // On Windows the null device is NUL and writing anything substantial to it + // (like redirecting a process' output) is extremely slow, as in, an order + // of magnitude slower than writing to disk. If you are using the descriptor + // yourself this can be mitigated by setting the binary mode (already done + // by fdopen()) and using a buffer of around 64K. However, sometimes you + // have no control of how the descriptor will be used. For instance, it can + // be used to redirect a child's stdout and the way the child sets up its + // stdout is out of your control (on Windows). For such cases, there is an + // emulation via a temporary file. Mostly it functions as a proper null + // device with the file automatically removed once the descriptor is + // closed. One difference, however, would be if you were to both write to + // and read from the descriptor. + // +#ifndef _WIN32 LIBBUTL_EXPORT int fdnull () noexcept; +#else + LIBBUTL_EXPORT int + fdnull (bool temp = false) noexcept; +#endif } #include -- cgit v1.1