Re: RE : RE : [Tsp-devel] Async-Write dans un consummer.

[Erk]

Le 03/05/06, PAGNOT, Robert <address@hidden> a écrit :
> Désolé, Robert doit y mettre son doigt ...

Tu es le bienvenu comme d'hab :))

> N'oubliez pas la sacro-sainte règle de séparation des canaux de commande
> et de données qui ont fait le bonheur de toute une génération de
> développeurs de moyens de test.

On n'oublie pas et je suis 100% d'accord.
J'ai toutefois un point de vue un peu différent sur l'async_XXX
mais sur le fond je suis d'accord pour ne pas mélanger sampling et "action".

> Déjà que je trouvais limite la notion "async-write" au sein de TSP ...

Oui je vois pourquoi tu dis ça...

> Je vois que l'engrenage continue son petit bonhomme de chemin,
> et dans la mauvaise direction .... Z-êtes en train de créer un "sync-write" :(((

NON et j'allais répondre à stéphane dans ce sens.
Ce n'est (à mon avis) PAS le rôle de l'async_write d'appliquer un profil
à une variable.

Je rappelle les objectifs des async_read/write:
[ce n'est que MON avis et on est bien sûr là pour en discuter]

0) Les async_read/write SONT DES COMMANDES
   asynchrones comme les autres qui ont pour effet de bord
   de transmettre des données MAIS sans garantie temporelle.
   Donc vouloir générer une entrée "propre" (rampe, sinus, etc...)
   avec l'async_write est illusoire et très certainement non
   répétable.

1) C'est pénible de devoir faire une demande de sample
   pour lire "1 valeur" d'où l'intérêt de l'async_read.
   Dans ce domaine il reste encore à implémenter le groupe
   asynchrone mais c'est encore un besoin différent

2) C'est très pratiques d'avoir un moyen de commande générique
   pour: activer/désactiver des log, provoquer une panne, etc...
   Et pour ça l'async_write c'est très bien.

3) Le CHOIX de ce que font effectivement l'asyn_read/write est laissé
   à la discrétion du provider (par l'entremise du GLU SPECIFIQUE qui le sert)
   donc le GLU seul autorise les async_xxx SI C'EST PERTINENT.
   Les fonctions GLU fournies par le default_glu INTERDISENT
   TOUTES les requêtes ASYNC_xxxx.
   Aujourd'hui seul le bb_provider autorise les async_xxx
   et on peut d'ailleurs contrôler sur quelle(s) variable's) c'est autorisé
   ou pas.

   D'ailleurs rien n'empêche un GLU d'accepter les async_write
   pendant certaines phases (init; sauvegarde contexte...) et les refuser
   pendant le reste du temps.

> Mon humble avis sur le sujet :
> si un besoin de transfert synchrone de données existe,

Il existe (et ce serait bien un sync_write)
mais je pense plutot que le besoin serait plutot
de l'ordre du "sync_exec" avec un exécuteur synchrone
côté provider mais là.

Je pense que c'est compliqué à implémenter de façon portable
car il nous faudrait une sorte de point d'entrée dans un séquenceur
côté provider.

Je pense également que la fonction pourrait être relativement
indépendante de TSP.

> il suffit de penser TSP à l'endroit (pas à l'envers !!!).
> En clair, positionnez un provider là ou sont les données
> et un consumer là où elles doivent atterrir.
> Quitte à coder un équivalent balck-board côté consumer.

Je ne suis pas sûr de voir ce que tu veux dire?
Le consumer devient provider des données qu'on
veut "sync_writé" et le provider consumer de ce flux?

> A+
>
>
>     Robert
>
>
>
> -----Original Message-----
> From: TSP   [mailto:address@hidden
> Sent: Wednesday, May 03, 2006 9:42   AM
> To: 'Transport Sample Protocol development   list'
> Subject: RE : [Tsp-devel] Async-Write dans un   consummer.
>
>
> Salut Stef.
>
> Je   doute qu'un tsp_async_write à 100hz écroule un provider bien fait. Pour moi,   un 
> truc compliqué comme des profiles ou des écritures à N Hz pendant  x   cycles devraient 
> être fait par des batchs, voir "téléchargés" dans le   provider.
>
> C'est pour cela que TARRRRRRGAAAAA intègre de l'écriture me fait   bizarre :
> A la   fois je trouve cela sympa pour une démo, mais en même temps cela me fait 
> peur   en utilisation opérationnelle.
> Je   vois bien un opérateur AIT maladroit de son clique droit, qui cartonne un  
>  symbole de conso électrique de la baie SCAO, et qui envoi un pain de 1000Volt  
>  sur le satellite. Surtout si on voit TARGA comme juste un loader de conf   
> synoptique figés, et non pas une IHM interactive.
>
> Pourrais tu rajouter une option de commande en ligne, qui active la   
> possibilité d'écrire, et qui sinon par défaut la désactive ? Ou trouver un   
> moyen de séparer les 2 ?
> Les   autres, un avis sur le besoin ???
>
> Y++
>
>
> -----Original Message-----
> From: Stef Euskadi     [mailto:address@hidden
> Sent: Tuesday, May 02, 2006 1:38     PM
> To: TSP
> Subject: [Tsp-devel] Async-Write dans un     consummer.
>
>
> Agur,
>
> Comme dit précédemment, j'implémente en ce moment l'async-write dans     TARGA.
>
> Quant à forcer un symbole avec une valeur, je me dis pourquoi ne pas     
> imposer un profil
> dans le temps, à une certaine fréquence qui est indépendante de la     
> fréquence du provider
> sur ce symbole.
>
> 1/ Y-a-t-il un besoin ? Moi, je trouve ça cool...
>
> 2/ Implémenter le truc revient à activer une succession     d'async-write.
> C'est peut-être pas top, mais il n'y a que ça pour l'instant.
> Je conçois aisément un async-write à 1 Hz, mais est-ce que faire     un
> async-write toutes les 10 ms (par exemple) n'écroule pas le provider     ?
>
> A+
>
> --
> --
> Euskadi.
>        ---------------------------------------------------------
>
> CE         COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE 
> SAURAIT         ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES 
>         FILIALES.
>
> SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A         MAL DIRIGE CE 
> COURRIER, MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT         UNE REPONSE 
> PAR COURRIER ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS         LE 
> DESTINATAIRE DE CE COURRIER, VOUS NE DEVEZ PAS L'UTILISER, LE         
> CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE COPIER, L'IMPRIMER OU EN         
> REVELER LE CONTENU A UNE TIERCE PARTIE.
>
>
>
> This email is for         information only and will not bind EADS Astrium SAS 
> in any contract or         obligation, nor its subsidiaries.
>
> If you have received it in         error, please notify the sender by return 
> email. If you are not the         addressee of this email, you must not use, 
> keep, disseminate, copy,         print or otherwise deal with         it.
>
> ---------------------------------------------------------
>
> ---------------------------------------------------------
>
>  CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT 
> ENGAGER DE QUELQUE MANIERE QUE CE SOIT EADS ASTRIUM SAS, NI SES FILIALES.
>
>  SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER, 
> MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER 
> ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER, 
> VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE 
> COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.
>
>
>
>  This email is for information only and will not bind EADS Astrium SAS in any 
> contract or obligation, nor its subsidiaries.
>
>  If you have received it in error, please notify the sender by return email. If 
> you are not the addressee of this email, you must not use, keep, disseminate, 
> copy, print or otherwise deal with it.
>
>  ---------------------------------------------------------
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel



--
Erk