State of the 0.7.1 release

[Trevor Saunders]

Hi,

not a code review, but here are my general thoughts.
While I don't have a specific issue with this being a hash table I don't believe
there is a good reason for it.   The array provides us what is escentially a
very good hash table in this case.  What I mean is this,we don't have to worry
about the possibility of collissions, and mapping values to keys is easy fast
and direct.  Also I doubt that this will efect memory ussage, if we are using
the array correctly we should have a fair higher density than the hash table
will.  However I'm fairly sure we aren't effeciently making use of the array
what I mean is I believe we leak a good number of file descriptors when we
initialize modules.  The effect of leaking these file descriptors is that there
is a large section of the array that won't be used.  SO I think the real thing
to work on here is to make sure we don't leak file descriptors, but since we
have the hash table, and it should have the same rough effect in the short term
we might as well stick with it.

Longer term I think we shouldn't have this global data structure, each client
should be handled by its own thread, which has private data for that client.

Trev

On Tue, Aug 10, 2010 at 02:28:16PM +0200, Hynek Hanke wrote:
> 
> >On 10.8.2010 11:52, Chris Brannon wrote:
> >>Did you ever see my patch to fix a possible buffer overflow
> >>in the speechd_connection_new() function?
> >Yes, thank you very much for noticing this. I think
> >however that it's better to convert SpeechdStatus
> >to a hash table, that only includes the active fd's.
> 
> Please see commit
> 
>    bc77a5025fa82b4c002793eaab518e8a311b2345
> 
> and let me know what do you think.
> 
> Best regards,
> Hynek
> 
> 
> _______________________________________________
> Speechd mailing list
> Speechd at lists.freebsoft.org
> http://lists.freebsoft.org/mailman/listinfo/speechd