Bonjour,
J’ai travaillé un peu sur les signaux sous Linux.
Et maintenant un nouveau terme "callback" (pour moi) me semble proche des signaux.
Pouvez vous m'aider à comprendre ce fameux callback?
Version imprimable
Bonjour,
J’ai travaillé un peu sur les signaux sous Linux.
Et maintenant un nouveau terme "callback" (pour moi) me semble proche des signaux.
Pouvez vous m'aider à comprendre ce fameux callback?
En clair, les callbacks ne sont pas "proches" des signaux, mais l'on peut dire que l'un des arguments de signal() est un pointeur de fonction, un callback.
Les callbacks sont assez rares sous nux, mais très utilisés dans l'API Windows.
Dans les langages orientés objet pur comme Java, on a tendance à utiliser des interfaces à la place. Sauf en .Net, où les pointeurs de fonction sont de retour sous le nom "delegate".
ben non.... Dès que tu parles d'IHM, le terme "callback" est courant.... Motif, XWindow et son ancêtre Athena les utilisent depuis 1978 :DCitation:
Envoyé par Médinoc
En fait c'est assez attaché à la notion d'événement...
Après, tout est question d'usage... Et il est parfaitement vrai que les fonctions appelées par signal peuvent être appelées callbacks (comme pourrait l'être d'ailleurs la fonction de tri appelée par qsort..), mais il n'y a aucun lien particulier entre signaux et callback, comme signalé ci-dessus.
En faite je fait un petit projet sur un microcontrôleur a la base des événements.Citation:
Envoyé par souviron34
(Suivant l'interruption je fais un tel traitement).
Qu’est ce que m'ajoute le callback?
Merci pour tous pour vos réponses rapides.:king:
je voulais dire historiquement......
Historiquement le terme "événement" a été lié au départ avec l'action déclenchée par un "widget" d'IHM (par exemple un bouton-poussoir).
Dans le cas de la signalisation, ce n'était pas historiquement nommé événement, mais juste signal/interruption...
Ce qu'on essaye de te dire, c'est que "callback" n'est qu'un terme, équivalent à la notion de "signal handling function" appelée lors du déclenchement d'un signal.
Par exemple lors d'un signal du type SIGIO, tu peux passer une fonction à signal. Cette fonction sera appelée lorsque l'événement se produira. On pourrait si on en a envie appeler cette fonction "callback"... Mais on peut ne pas l'appeler comme ça :mrgreen:
Une fonction callback c'est une fonction appelé à l'insu de ton plein gré en fait appelée par le système d'exploitation.Citation:
Envoyé par tun07
Elle est déclenchée/appelée en général par un événement que tu définis .
En l'occurence toi tu veux executer un code bien spécifique lorsque tu reçois par exemple le signal ctr+c
Elle n'est pas forcément appelée "à l'insu de ton plein gré". Elle l'est en programmation interruptible (signal()), mais dans d'autres circonstances, on sait quand la fonction sera appelée:
- Avec qsort(), la fonction de comparaison ne sera appelée QUE pendant qsort()
- Pour des fenêtres Windows (programmation événementielle), la fonction sera appelée dans GetMessage(), PeekMessage() (si, si), DispatchMessage() et des fonctions comme DialogBox() et MessageBox(), qui contiennent leur propre boucle de messages.
- La callback d'EnumWindows() sous Windows ne sera appelée QUE pendant EnumWindows()
- etc.
FAUX...Citation:
Envoyé par hegros
C'est de ton plein gré, et ça n'est pas forcément par le système d'exploitation...
Si tu n"en définis pas, de fonctions, dans signal ou dans les IHM, il ne se passe rien pour toi.. Et si tu en définis, c'est TOI qui crée la fonction.
De plus, pour les GUI, c'est pas l'OS, mais le gestionnaire graphique qui dispatche...
Médinoc on a été ensemble :mouarf:
Certe signal() mets le state du signal à 1 mais n'appelle en aucun cas directement la fonction callback c'est le système qui s'en charge.Citation:
Envoyé par Médinoc
Bravo, tu as cité comme argument opposé le seul qui allait dans ton sens.
Beh non tu enregistres une fonction tu ne l'appeles jamais directement dans ton code sinon ca servirait à rien.Citation:
Envoyé par souviron34
:applo: Ah bon ?Citation:
Envoyé par Médinoc
Ben oui, mon post dit clairement que la fonction EST appelée à l'insu de ton plein gré si tu utilises signal() : programmation interruptible.
C'est sur les autres points (contre-exemples, disant que ce n'est pas forcément à l'insu du plein gré) qu'il est en opposition.
Oui mais celui qui dispatche vers cette fonction quand l'événement se produit ??Citation:
Envoyé par hegros
Pour signal oui c'est le système.
Mais pour événment graphique, c'est le moteur graphique (je ne sais pas comment ça s'appelle sous Windows, mais sous Unix/linux, en X, tu as le serveur X), qui n'est pas un OS.....
Arrête s'il te plaît tu te fais du mal pour rien :mrgreen:Citation:
Envoyé par Médinoc
Dans ce cas elle sert à rien cette fonction signal autant appelé directement ma fonction .
Pour la partie graphique ( tu fais bien de te rattraper 8-) ) je ne dis pas.Citation:
Envoyé par souviron34
je me rattrape pas, c'est ce que j'avais dit dans mon post, en même temps que Médinoc ...
:P
Là, j'y comprends plus rien.Citation:
Envoyé par hegros
Je croyais que TU disais qu'un callback était une fonction appelée à l'insu du plein gré ?
Et moi je dis: Oui pour signal(), non pour d'autres. En clair: Pas toujours.
Ok on va dire cela mais n'empêche qu'alors vous êtes HS parce que le PO parle de signaux sous linux et à mon avis il ne parle pas de ce qui touche à la partie graphique mais bien des signaux SIG_Quelquechose
et en plus, comme avait cité Médinoc, par exemple la fonction que tu passes à qsort est également une "callback", pas appellé par l'OS, mais par la bibliothèque...
re :P
C'est vrai :mrgreen: Cependant le PO n'a fait à aucun moment mention de qsort ;)
Désolé mais il demandait des explications sur le terme callback...Ce qu'on a donné ;)Citation:
Envoyé par hegros
Le posteur originel ne parle pas "de signaux", mais de callbacks et du lien entre callback et signaux.
Je ne vois pas en quoi il est HS de montrer l'/les autre(s) contexte(s) d'utilisation des callbacks...
C'est écrit dans le titre callback et signaux ce n'est quand même pas moi qui l'ait inventé.
Moi non plus, et je n'ai pas non plus inventé cette phrase:
PS: On s'amuse comme des fous à argumenter, hein ? :aie: Encore un peu et on aura notre première mouche !Citation:
Envoyé par le posteur originel
Edit: Ben si, justement, tu dis :P
Mais c'est appliqué au signaux.:aie: Enfin un coup de général ne fait pas de mal non plus je ne dis pas.Citation:
Envoyé par Médinoc
Il est où le PO jamais là quand on a besoin de lui un peu comme le client :mouarf:
L'intérêt principal des callbacks est la générécité. Par exemple, la fonction qsort() du C effectue le tri d'un tableau quelque soit le type de ses éléments. Belle performance qui est due à l'utilisation d'un 'callback' (ou fonction utilisateur) pour fournir ce qui manque à la fonction de la bibliothèque, c'est à dire le moyen de faire la comparaison entre 2 éléments du tableau. Cette partie est 'déléguée' à l'utilisateur pour plusieurs raisons évidentes :Citation:
Envoyé par tun07
- Le critère de tri dépend du choix de l'utilisateur et de ses données
- Seul l'utilisateur connait le détail des données (type etc)
Dans une application, ce n'est pas forcément très intéressant, sauf si on travaille dans une organisation du code très segmentée (protocole par couches, par exemple). Les appels vers les couches inférieurs se font par appels (calls) et les appels vers les couches supérieures se font par callbacks()
Ca sert aussi à créer des composants logiciels.
http://emmanuel-delahaye.developpez.com/complog.htm
(Ici, l'exemple est trivial, mais ça peut aller jusqu'à une machine de guerre comme GTK+...)
Un exemple que j'ai utilisé en embarqué pour faire des machines à états :
http://emmanuel-delahaye.developpez.com/clib.htm
Module FSM
j'était pas connecté la nuit.Citation:
Envoyé par hegros
enfin c'était clair.
Merci pour Medinoc,souviron34 et hegros.aussi pour votre disscussion .
Merci pour EMannuel.