C/C++ : attendre plusieurs évenements dont l'ouverture d'une socket

[destroyedlolo]

Bonjour,

Sous Unix, je développe un démon "écoute" plusieurs sources d'événements extérieurs (timer, inotify, ...) grace à la fonction "poll()".
Parmi eux, la connexion sur un socket Unix. Et c'est là que le bas blesse ... comment la rendre non bloquante ?

Je m'explique, pour écouter une socket, s'enchainent les fonctions :

• socket()
• bind()
• listen()
• accept()

Accept() bloque jusqu'à ce qu'une connexion arrive ... donc les autres événements ne seront pas pris en compte.
Alternativement, je peux le mettre NON BLOQUANT mais il faut alors faire une boucle qui l'appele régulièrement à la mode busywait.

Franchement, ne peut-on pas faire mieux ? Tout passer par poll() et ne lancer le accept() que si une connection est en attente ?

Merci pour vos idées
-----

[pm42]

Pourquoi ne pas passer en multithreading ?

[polo974]

La commande incontournable: man
Et le fameux cri de guerre "RTFM ! ! !"

man accept

       In order to be notified of incoming connections on a  socket,  you  can
       use  select(2),  poll(2), or epoll(7).  A readable event will be deliv‐
       ered when a new connection is attempted and you may then call  accept()
       to  get  a  socket for that connection.  Alternatively, you can set the
       socket to deliver SIGIO when activity occurs on a socket; see socket(7)
       for details.

(il faut toujours installer man et les données associées)
(souvent le man traduit est moins bon que le man en anglais donc éviter les données traduites)

il faut donc mettre le socket d'écoute dans le select (ou autre poll) et quand ça "mord", lancer le accept.

belle explication:
https://www.ibm.com/docs/en/i/7.1?to...king-io-select

[destroyedlolo]

Merci, c'est exactement ce qu'il me fallait

Pour le multithreading, c'est ce que je pensais faire si je n'avais pas trouvé 1 autre solution plus "légère".

Bonnes fetes.

[A voir en vidéo sur Futura]

[pm42]

Pour le multithreading, c'est ce que je pensais faire si je n'avais pas trouvé 1 autre solution plus "légère".

J'ai fait du select/poll pendant longtemps notamment parce qu'il n'y avait pas d'alternatives, les threads n'étant pas encore disponibles. Je ne trouve pas le multithreading spécialement plus lourd. Au contraire, cela fait plutôt du code simple et cela permet de gérer autant de types d'évènements que possible, de faire des calculs ou des affichages tout en attendant si nécessaire, etc.
Pour un démon, on peut cependant en discuter et si poll/select suffit, ce n'est pas une mauvaise solution.

[destroyedlolo]

J'ai fait un "gros" framework (Séléné) qui est en effet fortement multi-threadé mais qui utilise aussi des poll() pour gérer des événements extérieurs liés à ma domotique : comme ces événements arrivent n'importe quand, et entrainent d'autres actions qui peuvent être longues genre mettre à jour une GUI ou lancer des automatismes, le multi-treading avec des queues internes s'est imposé et permet de résoudre pas mal de problèmes de concurrence que j'aurai eu en "simple thread".

Maintenant, ma nouvelle application est un gestionnaire d'intégrité de backup très longue durée (plusieurs dizaines d'années) avec une base d'état en mémoire.
Je n'en suis qu'aux prémisses mais je pars pour le moment sur du mono-thread : à nouveau des pb de concurrences mais ici, il faut justement les éviter et le fait que l'appli soit bloquée pendant plusieurs minutes (genre durant la vérification de l'intégrité d'un répertoire de vidéos), n'a pas d'importance. Bon, je changerai peut-être d'avis par la suite

[pm42]

Ok tu as l'air de savoir ce que tu fais et ton argumentaire me semble parfaitement cohérent.
Bon développement.