tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Tsp-devel] Achtung


From: DUFRENNE, Yves
Subject: [Tsp-devel] Achtung
Date: Tue, 14 Sep 2004 19:05:01 +0200

Salut les keums.
Pour ceux qui aiment la poesie, jetez ce mail.
 
Pour les autres :
- J'ai remplacé la philo de get_next_item par du push_next_item puis commit dans le datapool. Cela a au passage suprimé le thread coté datapool, et voir celui coté glu_stub.
- Pendant que j'y etais, j'ai supprimé toutes les notions de datapool non global: Il est beau, grand, et unique, comme les tailles de maillots de bain sur la plage.
- Comme Eric me tartinait les oreilles avec ses 200 000 symboles à mettre à jours (tout cela pour me faire bisquer avec Alactel qui fait des trucs + mieux que Matra), j'ai crée une liste inversée des symboles voulus par les divers clients, ce qui fait que le glu peut ne mettre à jour que la portion congrue des symboles demandés, et non pas la totalité. Voir code du glu_stub pour + d'info.
 
Cela marche pour le stub, mais les autres providers ne compilent plus du coups. Que chacun en prenne un pour le mettre à jour facon stub.
 
Par contre, il reste quand meme que l'API en callback est un peu merdique. Je suis d'accord avec Robert sur l'idée de renverser l'API. C'est le GLU qui ferait les appels :
    - TSP_provider_init
    - Creation de sa liste de symb
    - set_frequency, set_liste vers le datapool
    - TSP_run
    _ While 1 : TSP_datapool_push
...
 
A voir quand j'en aurais le courage. Merci de me dire si vous voyez une regression sur les providers, en particulier pour les passifs.
 
Y++
 

Attachment: important_notice.txt
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]