Displaying 4 results from an estimated 4 matches for "hive_t".
Did you mean:
hive_h
2018 Feb 10
0
Re: [PATCH] Add a cache for iconv_t handles to hive_t
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}
> instead of
2018 Feb 09
0
Re: [PATCH] Add a cache for iconv_t handles to hive_t
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/$ENCODING.so to be opened and mapped.
>
> The iconv_t handles are now cached in the
2018 Feb 09
2
[PATCH] Add a cache for iconv_t handles to hive_t
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 the hive_h struct; they are
opened on-demand and re-used.
On my ~10 year old Lenovo T60, I have
2018 Feb 09
3
[PATCH] Add a cache for iconv_t handles to hive_t
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 the hive_h struct; they are
opened on-demand and re-used.
On my ~10 year old Lenovo T60, I have