[Top][All Lists]
[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++
important_notice.txt
Description: Text document
- [Tsp-devel] Achtung,
DUFRENNE, Yves <=