[interfacekit] Re: __mime_table
- From: "Daniel Reinhold" <danielr@xxxxxxxxxxxxx>
- To: interfacekit@xxxxxxxxxxxxx
- Date: Mon, 12 Aug 2002 12:43:07 CDT
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:
