[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Tsp-devel] hypothèses sur TSP_write
From: |
Eric NOULARD |
Subject: |
Re: [Tsp-devel] hypothèses sur TSP_write |
Date: |
Tue, 24 May 2005 22:43:27 +0200 |
Le mardi 24 mai 2005 à 17:15 +0200, CHOQUET, Mathias a écrit :
> Bonjours,
> Voici les hypothèses et choses à faire pour tsp-write.
> J'aimerais avoir vos avis.
>
> Merci.
> ----------------------
> Hypothèses principales
> ----------------------
>
> 1)Le Consumer peut écrire sur n'importe quelle donnée du provider même
> celles qui n'ont pas été
> séléctionnées.
Ok.
>
> 2)Le provider peut refuser cette écriture et dans ce cas renvoyer -1 au
> consumer.
Toujours Ok.
>
> 3)C'est à l'utilisateur de gérer ce refus aisni que les problèmes de
> concurrences d'écritures.
> (ce changement d'hypothèses a été décidé avec Yves Dufrenne Mardi 24 Mai)
> C'est à l'utilisateur
> qui va écrire la partie GLU (GLU_init, CLU_thread...) de gérer ce problème
> et non à tsp.
> L'hypothèse est que l'écriture se fait pour une donnée du simulateur, c'est
> donc au simulateur
> de gérer lui même ce problème de concurrence.
Exact.
>
> 4)On suppose que le provider et le consumer connaissent grâce au p_g_i le
> type de la donnée envoyée.
>
> 5)Pour les problèmes d'endianité, j'utiliserais la glib.
Il me semble qu'il y déjà certains bout de code/macro dans
tsp/src/core/include/tsp_const_def.h
notamment:
TSP_ENCODE_INT
TSP_ENCODE_DOUBLE_TO_UINT64
Il me semble aussi qu'on voulait éviter la dépendance
avec la glib, reste à ré-évaluer si le jeu en vaut la chandelle.
>
> 5)Schéma :
Ben là j'ai un peu de mal car les lignes sont wrappées...
Pourrais-tu refaire un schéma et le transmettre en jpeg ou png par
exemple.
<pub obligation_d_achat="non">
Pour les schémas dia est sympathique:
Pour gnome
http://www.gnome.org/projects/dia/
Ou winXX
http://dia-installer.sourceforge.net/
</pub>
>
> ___________
> ____________ _________| |_______
> ______________
> | | | | | | |
> |
> | consumer | rpc_req| | Core | GLU | | provider
> |
> | |---------->| tsp_rpc | | | req |
> coté |
> | | | | | |--------->|
> utilisateur |
> | | retour| | | | | (gestion
> des |
> | -d- |<----------| -a- | -b- | -c- |
> retour |
> mutex) revoi |
> |____________| |_________| |_______|<---------| -1 si
> refus |
> |_____________|
> |___envoi______|
>
> ----------------------------------------------------
> coté client (coté C et Java (à faire pour les 2!)) :
> ----------------------------------------------------
>
> 1) ds tsp_rpc.x : rajouter le prototype de la fonction int
> TSP_ASYNC_SAMPLE_WRITE(
> int provider_global_index, void* value, size_t
> valuesize) (-a-)
>
> 2) ds tspConsumer.c & .h : rajouter l'appel de la fonction
> TSP_ASYNC_SAMPLE_WRITE sous
> forme d'une fonction de tspConsumer (-d-).
>
> 3) ds tsp_client.c & .h : rajouter
> TSP_async_sample_write(async_write_t,TSP_server_t) et gérer
> les problèmes d'endianités (big et little).
>
> -----------------------
> coté serveur (coté C) :
> -----------------------
>
> 4) ds tspprovider.c et .h : rajouter la fonction tsp_async_sample_write qui
> sera appelé par
> TSP_ASYNC_SAMPLE_WRITE. deplus, il faut proposer
> une API de
> deux fonctions tsp_write_lock et
> tsp_write_unlock pour la gestion
> de l'exclusion_mutex.(-b-)
>
>
> 5) ds glue_sserver.h : rajouter le proto de la fonction et les explication
> sur les problèmes de
> concurrences. Ces protos sont les fonctions GLU
> implémenter dans les
> providers (-c-)
>
> 6) ds tsp_server.c & .h : rajouter
> TSP_async_sample_write_1_svc(async_write_t) et gérer
> les problèmes d'endianités (big et little).
>
>
> Mathias choquet
> _______________________________________________ Tsp-devel mailing list
> address@hidden http://lists.nongnu.org/mailman/listinfo/tsp-devel