On Sat, Feb 10, 2018 at 01:40:36AM +0100, Hilko Bengen wrote:
> * Richard W.M. Jones:
>
> >> +threadlib
> >> '
> >
> > Probably better to keep these sorted.
>
> When I rebuilt from scratch, it turned out that threadlib was not
> enough. Using the "lock" module with the gl_lock_{init,lock,unlock}
On Fri, Feb 09, 2018 at 03:52:20PM +0100, Hilko Bengen wrote:
> diff --git a/bootstrap b/bootstrap
> index bd82477..373fad8 100755
> --- a/bootstrap
> +++ b/bootstrap
> @@ -75,6 +75,7 @@ vc-list-files
> warnings
> xstrtol
> xstrtoll
> +threadlib
> '
Probably better to keep these sorted.
> +ty
It was brought to my attention that dumping a registry hive causes a
lot of time spent in disk I/O activity because iconv_open() and
iconv_close() are called for every key. Every iconv_open() call causes
/usr/lib/.../gconv/$ENCODING.so to be opened and mapped.
The iconv_t handles are now cached in
On Fri, Feb 09, 2018 at 01:30:03PM +, Richard W.M. Jones wrote:
> (4) Replace any calls to pthread_mutex_* with gl_lock_*. It's
> probably not necessary to check return codes, unless they need to be
> recursive in which case use gl_recursive_lock_* instead.
Two sentences jammed into one there
On Fri, Feb 09, 2018 at 01:52:52AM +0100, Hilko Bengen wrote:
> It was brought to my attention that dumping a registry hive causes a
> lot of time spent in disk I/O activity because iconv_open() and
> iconv_close() are called for every key. Every iconv_open() call causes
> /usr/lib/.../gconv/$ENCOD
It was brought to my attention that dumping a registry hive causes a
lot of time spent in disk I/O activity because iconv_open() and
iconv_close() are called for every key. Every iconv_open() call causes
/usr/lib/.../gconv/$ENCODING.so to be opened and mapped.
The iconv_t handles are now cached in
