Asynchronisme avec boost::asio
Bonjour,
J'essaye de regarder un peu ce qui existe au niveau d'implémentations asynchrones pour les communications socket, et il y a quelque chose que je ne comprends pas bien.
Avant de me renseigner, j'ai commencé par développer mon propre système d'asynchronisme (côté client):
- Une tâche qui fait évoluer une machine d'état et qui effectue des écritures sur socket.
- Une tâche qui lit de façon bloquante les réponses.
=> Le principal problème est que la réception se fait dans un contexte différent.
Maintenant, en me renseignant sur les méthodes proposées par boost::asio, je tombe sur ceci:
Citation:
Pour pallier à ce mode de fonctionnement (bloquant, synchrone), on pourrait lancer la réception de données dans un thread par exemple. On s'affranchirait ainsi du problème de la réception synchrone. Par contre, le développeur devra dans ce cas gérer les accès concurrents lui- même
Cette citation confirme bien le problème de contexte constaté ci-dessus. Par contre, ce que je ne comprends pas, c'est que dessous, ils mettent par exemple l'API "async_read":
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
|
void completion_handler(const boost::system::error_code& error)
{
std::cout << "Terminé" << std::endl;
}
void Mafonction()
{
//Lecture asynchrone
boost::asio::async_read(socket, boost::asio::buffer(msg),
boost::bind(&completion_handler, boost::asio::placeholders::error)
);
std::cout << "Ca s'affiche ! " << std::endl;
} |
Ici, une callback est passée en paramètre de la fonction async_read. Mais que fait réellement async_read ? J'ai tendance à penser qu'elle crée une tâche en sous-marin qui réceptionne ce qu'il y a dans la socket puis appelle la callback à son arrivée. Du coup, la callback serait appelée dans un contexte différent, et l'on peut imaginer des accès concurrent également entre la callback et la tâche qui a effectué l'émission. N'est-ce pas ?
Julien.
