tsp-devel
[Top][All Lists]
Advanced

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

Re: [Tsp-devel] TSPWrite


From: Eric.NOULARD
Subject: Re: [Tsp-devel] TSPWrite
Date: Wed, 11 May 2005 14:51:12 +0200

Très bonne chose le sample write.
Celà corresponds à une tâche projet.

https://savannah.nongnu.org/task/?func=detailitem&item_id=3511

Je t'affecte la tâche et tu pourras également
y poster des faits marquant et gérer son avancement.

Concernant le comment voici quelques remarques.

Il faut effectivement modifier le tsp_rpc.x
mais personnellement j'appellerais la méthode/fonction

TSP_ASYNC_SAMPLE_WRITE

(de même il y aura plus tard ou dans le même
 temps si tu te sens de le faire TSP_ASYNC_SAMPLE_READ)

ASYNC car la fonction devra implémenter une
écriture ASYNChrone. Et on pourra imaginer (plus tard)
des écritures 'synchrones' qui seraient réalisées
en faisant:

TSP_REQUEST_SYNC_SAMPLE_WRITE(tsp_request_sync_sample_write_t* )
puis
TSP_REQUEST_SYNC_SAMPLE_WRITE_EXEC()...
TSP_REQUEST_SYNC_SAMPLE_WRITE_STOP()...

En gros une ecriture asynchrone ne garantie pas de délai entre
l'appel du consumer et l'écriture effective dans le provider.
Une écriture synchrone pourrait le faire si on imagine
qu'elle fonctionne dans le sens "inverse" du request_sample.

En ce qui concerne l'API je serais plutôt pour:

tsp_async_sample_write(TSP_symbol_t symbol, void* value, size_t valuesize)

en definissant (dans tsp_rpc.x)
struct TSP_symbol_t {
   int provider_global_index;
   opaque xdr_tsp_t[4]; /* type TSP */
}

De cette façon on saura comment xdriser la valeur à transmettre.

> Avec cela, c'est dans le coté glue que on connait le type
> du symbole, et que l'on peut faire les bonnes conversions (double, int,
> string, ...).

Car avant de faire la conversion dans le glu il aura bien fallu
passer cette valeur sur le réseau via XDR et donc comme le GLU ne saura
pas 'a priori' l'endianité du consumer qui lui a envoyé la valeur
ben il faudra faire:

   Consumer                       Provider
natif --> xdr <---- reseau ----> xdr --> natif

C'est le même problème qu'on a sur la lecture de la socket
sur laquelle on reçoit les samples.
Les VALEURS doivent être converti en XDR au départ et en NATIF
depuis XDR à l'arrivée.

Il y a une optimisation possible mmise en place par Stéphane Galles
(option de compil je crois) pour eviter la double conversion
au cas ou consumer et provider on la même endianité.

MAIS ce ne doit pas être le cas par defaut.

Dans le cas de l'appel RPC tsp_async_sample_write il faut donc
passer le void* contenant la valeur du type natif ET les infos
pour le convertir XDR d'où le TSP_symbol_t.

Aujourd'hui on ignorera le xdr_tsp_type car on ne gère que
les 'double' mais il faut prévoir la place dans l'API.

Eric

-----Original Message-----
From:   address@hidden on behalf of CHOQUET, Mathias
Sent:   Wed 5/11/2005 1:12 PM
To:     'address@hidden'
Cc:    
Subject:        [Tsp-devel] TSPWrite
Bonjours,
Je voudrais ajouter la fonction TSPwrite qui permettrait au consumer
d'écrire des informations sur des données de la SampleList et de les envoyer
au provider.

Yves Dufrenne m'a proposé la solution suivante :

Mettre TSPwrite dans la partie rpc (dans le tsp_rpc.x) avec une API du genre
TSP_EXEC_SAMPLE_WRITE, qui prends en parametre un global_provider_index
(l'id du symbole),  et un buffer non valué (void *) et une longueur (exemple
8 pour un double). Avec cela, c'est dans le coté glue que on connait le type
du symbole, et que l'on peut faire les bonnes conversions (double, int,
string, ...).

Questions
------------
Y a t'il déjà un travail de fait sur ce sujet (documentation, idées,
code....) ?

Avez-vous des conseils et des suggestions à me faire ?

Pensez-vous que c'est une bonne idée ?



reply via email to

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