[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 not a bug although it is admittedly a bit disconcerting if you 
don't know what's going on.

On the x86 platform the reason you see the same sizes show up again and 
again because the executables have some of their sections rounded up to 
a minimum size (a gcc "feature") and the resource chunk also has a 
minimum size. 
. . .

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).


>>> One other MIME related thing I should mention is that, while 
speaking 
>
>>> with AnEvilYak a few weeks ago, he noted that the automatic MIME 
>>> sniffer on his system never runs when he has something like SETI 
>>> running in the background all the time. He mentioned that it might 
be 
>
>>> nice if we could implement a way around this, as he always has to 
>>> manually identify files otherwise.
>>
>>Very good point. Perhaps it is sufficient to not just to look, if 
there
>>are spare CPU cycles at all, but, in case there are no spare cycle, 
to
>>analyze what priority the processes have that consume most of the 
>cycles.
>>Supposing that SETI and similar background number crunching processes 
>have
>>the lowest imaginable priority, this seems to be a reasonable 
strategy.
>
>Another possibility, which might be a bit too hackish, would be to set 
>up a BMessageRunner so that our sniffing happens on a reasonably 
regular 
>schedule regardless of what else is going on.
>
>e
>
>Necessity is the plea for every infringement of human freedom. It is 
the 
>argument of tyrants; it is the creed of slaves.
>       -William Pitt, British prime-minister (1759-1806)
>
>

Other related posts: