Angus Robertson - Magenta Systems Ltd wrote:
>>> We don't want to open and load a text file each
>>> time a new type is found.
>> True, that would be dog-slow.
> 
> We need to think about Linux/OSX, this will be first use of registry
> access in ICS, I've already done some stuff to help decoding MIME
> email content.

I don't know yet how to get the MIME type list from non-windows OS, 
however I'm confident that will work somehow :) 

> 
>>> I agree that memory is needed for all the MIME types, so it
>>> probably
>>> wants to be a global object shared between multiple servers, maybe
>>> with the existing code left as a default.
>> 
>> IMO memory use of 200-400 short MIME type strings is minor, nothing
>> we should worry about today.
> 
> Are you sure? If there are say six listen sockets, do we really want
> to load and keep separate MIME tables for each?

I'm quite sure. A singleton or global object would just introduce
new multi-threading issues. Access to such a global has to be 
synchronized somehow in multi-threaded environments.
Also, does it actually happen frequently that more than one or two servers
are running in the same app? Well, we should realy find a reliable way to
make a server capable to listen on more than just a single interface (first
attempt available in the IPv6 branch) in order to eliminate the need for
one instance per interface. 

> 
>> Lookups from a hash table are hell-fast, until there are collisions.
> 
> I've only used binary search lists, mostly written before Delphi got
> hash lists, and was expecting more than a few hundred items so there
> would be several tests to find an item.

In this case a hash table, as available with THashedStringList in
IniFiles.pas for D7+, is the faster choice, provided the list is not 
changed _very frequently once it has been built.

-- 
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Reply via email to