[interfacekit] Re: __mime_table

> I'm not sure if this is useful to you guys, but I had a short email 
> exhange with Dominic Giampaolo a couple of years ago where he 
> mentions 
> the mime sniffer.
> 
> I was noticing that the executable file sizes of C programs I wrote 
> would routinely grow beyond their original smaller size to certain 
> stepped-up, fixed sizes after a period of time. I mailed Dominic 
> about 
> it, wondering if this was some kind of bug. He replied:
> 
> . . .
> What you're seeing is the result of the mime sniffer running.  The 
> mime 
> sniffer is a tool that runs around in the background and sets the 
> mime 
> type of untyped files.  When it encounters an application, it does a 
> little bit more and adds some resources to the file as well.  
> Resources 
> are simply tacked on to the end of the application binary (in 
> addition 
> to being stored in attributes).  This is why you see the file size 
> grow.
[...]

It's good to know, that the registrar also creates an app file info, if 
there's none. I believed it would only perform what the functions 
create_app_meta_mime() and update_mime_info() do. When these functions 
are told to work asynchronously the registrar runs another thread -- 
"mime_updater" or something like this.
BTW, the FileTypes tracker add-on adds the app file info as well -- 
when opening the file, not only when saving!

> Then, near the end, he made one more interesting comment:
> 
> . . .
> The mime sniffer (which is a thread in the registrar) starts sniffing 
> after 20 minutes of idle time.
> . . .
> 
> So that appears to be the methodology according to Dominic -- 20 
> minute 
> of idle time, and the sniffer gets re-activated. People running SETI 
> (and other CPU intensive stuff) probably never accumulate that amount 
> of idle time. Maybe this isn't ideal, but if we implement it this 
> way, 
> then we at least match what R5 did (does).

Well, I don't think, it's much harder to find out whether only low-
priority threads are eating the CPU cycles than to check whether the 
machine is basically idle. It wouldn't harm to improve the situation, 
if didn't take significantly more time. I guess the guy who will 
implement this (in phase 4 IIRC), will certainly do the right thing. Be 
faithful. ;-)

CU, Ingo

Other related posts: