Re: chan copy -command callback not executed

Pat Thoyts <[email protected]> Mon, 27 Sep 2010 16:27:19 +0100
Newsgroups gmane.comp.lang.tcl.starkit
Message-ID <[email protected]>
On 27 September 2010 14:48, jdc <[email protected]> wrote:
> Hi,
>
> When running the 'Wub' webserver from within a starkit I observe the
> following:
>
> - some images are served to the clients =A0without problems (mostly jpeg
> and gif)
> - some images are not served (mostly png)
>
> When images are not served, I seems their chan copy -command callback
> is not executed. Looking at the file descriptors, I noticed the file
> descriptors for working images are named 'rechan???', while file
> descriptors for non-working images are cnamed 'mk???'. This difference
> comes from the way files are opened in vfs::mk4::open. Working images
> have a different =A0'size' and 'csize', non working have the same size
> and csize.
>
> Forcing vfs::mk4::open to always use the 'mk4vfs::direct' path,
> copying the file content to memory, solves this issue, and all images
> are served to the client. But this hack surely isn't addressing the
> root cause of this issue.
>
> Any ideas how to solve this issue?
>
> Jos.

The mk4vfs layer stores files by zlib compressing them into a blob in
the database. If the compressed size is the larger than the original
size then it just stores the file. PNG files are likely to hit this.
Then when reading the data, it looks for the zlib magic to enable
decompression. I suspect that your PNG files have compressed segments
and therefore trigger this. So we saved without compression but are
decompressing on read. I think there are some variables to fiddle with
in the mk4vfs stuff to disable the use of compression. If this turns
out to be correct, you might want to hack the vfs to avoid this when
the name matches *PNG.

size is the original data size, csize is the size of the database blob.

--=20
You received this message because you are subscribed to the "starkit" group=
.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to starkit-unsubscribe@googlegro=
ups.com
For more options, visit this group at http://groups.google.com/group/starki=
t?hl=3Den