printf () après UNIX fork ()

Je travaille sur un service de communication serveur serveur très simple pour apprendre le concept. Côté serveur, j’ai une fonction qui accepte les connexions et permet au client de communiquer avec le serveur. Lorsqu’un client connecté envoie un message au serveur, il envoie un message de réponse au client. Du côté du client, je crée un thread qui écoute les messages / réponses du serveur. Ce thread exécute simplement une boucle qui vérifie si read () renvoie plus de 0 octet si le message est imprimé. Les autres threads gèrent les entrées utilisateur et envoient des messages au serveur.

Maintenant à la question: j’ai quelques lignes de code qui écoute les messages du serveur

void readFromServer(int fileDescriptor) { int nOfBytes; char buffer[512]; while(1){ nOfBytes = read(fileDescriptor, buffer, 512); if(nOfBytes > 0) printf("Server says: %s \n\n>", buffer); } } 

Cela signifie que lorsqu’un message provient du serveur, je voudrais le représenter comme ça

 >Serever says: Something >| 

mais pour une raison quelconque ce que je reçois est ce

 >>Server says: Something | 

(| pipeline représente le curseur dans la fenêtre de la console)

Est-ce que quelqu’un sait pourquoi c’est comme ça? Et y a-t-il une solution à ce problème?

Merci d’avance.

EDIT ————> Le fork () est fait dans la fonction principale comme ceci

 int pid = fork(); if(pid != 0) readFromServer(sock); 

Très probablement, la mise en mémoire tampon des stdio est un obstacle. Pour que la stdout ne soit pas tamponnée, utilisez

 setvbuf(stdout, 0, _IONBF, 0); 

une fois avant de commencer les E / S. Ceci est une fonction C89, déclarée dans . Votre page de manuel contient tous les détails.

Le double > dans votre exemple de sortie n’est pas expliqué par le code que vous avez présenté. Peut-être que votre autre thread imprime également sur stdout .

L’absence d’un > à la fin est presque certainement due au fait que stdout est mis en tampon par défaut, ce qui signifie qu’il accumule la sortie jusqu’à ce qu’il reçoive une nouvelle ligne et l’imprime une ligne à la fois. Vous pouvez contourner ce problème en désactivant la mise en mémoire tampon, comme l’a suggéré Jens, ou en appelant fflush(stdout) après l’impression.

Sachez aussi que votre utilisation de read() est discutable. Il n’est pas certain de lire un message entier de l’autre côté en un seul appel, même si ce message est inférieur aux 512 octets que vous spécifiez. De plus, votre boucle va tourner si l’autre côté ferme la connexion réseau, chaque appel read() renvoyant immédiatement -1 sans être bloqué.

Vous écrivez l’invite de saisie “>” à partir d’un thread et les instructions du serveur à partir d’un autre.

Pour créer l’interface utilisateur souhaitée, vous devrez investir dans le développement de la technologie curses (ou termcap) et de la synchronisation des threads ou de l’appel système select () à lire depuis le clavier et le socket.