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