On Sat, 2003-11-08 at 23:39, Gonzalo A. Arana wrote:
You'll want to have a sync layer over whatever
allocator your compressor/decompressor use).
Ouch! zlib uses malloc and I can't change that without patching zlib,
can I?
So, no mempools can be used for those mallocs, right?
zlib allows
On Sat, 8 Nov 2003, Gonzalo A. Arana wrote:
Ouch! zlib uses malloc and I can't change that without patching zlib,
can I?
So, no mempools can be used for those mallocs, right?
No, but malloc is threads safe to begin with.
Regards
Henrik
On Sat, 2003-11-08 at 23:39, Gonzalo A. Arana wrote:
You'll want to have a sync layer over whatever
allocator your compressor/decompressor use).
Ouch! zlib uses malloc and I can't change that without
patching zlib,
can I? So, no mempools can be used for those mallocs, right?
On Fri, 7 Nov 2003, Gonzalo A. Arana wrote:
1) make statCPUUsage public? (I guess this is the best).
If so, I would need to know cpu usage with better resolution than 1
minute. Is it possible (using squid API rather than system calls)?
Won't give you very accurate information
On Fri, 7 Nov 2003, Gonzalo A. Arana wrote:
Squid-3 does not have an API for running jobs asyncrhonously, right?
Not really no.
But if you limit yourself to platforms having threading support is is a
normal inter-thread message problem. To my knowledge all platforms have
threading support
On Sat, 2003-11-08 at 08:18, Gonzalo A. Arana wrote:
My instinctive reaction is to run the compression
decompression in a separate thread. If the queue to the
compression/decompression engine is
large, decrease the compression level used.
Good instinct :-)
Squid-3 does not have an
