J'ai un fil de travail dans ma demande qui est responsable de trois choses différentes. Les demandes de participation de deux des emplois sont activées dans les files d'attente que j'ai écrites, l'autre travail est activé lorsqu'une demande s'allume sur un flux réseau. J'aimerais que mon fil de travail attendra quand il n'y a pas de travail à faire. Ceci est facile avec les deux files d'attente lorsqu'ils exposent un manuelResetEvent défini lorsqu'ils ont des articles, mais la réseaux ne semble pas avoir ceci. Le réseau NetworkStream a été récupéré à partir d'un tcpclient.
Qu'est-ce que je suis après le code qui ressemble à quelque chose comme ceci: p>
while (notDone)
{
WaitHandle.WaitAny(new WaitHandle[] { queue1.HasData, queue2.HasData, netStream.HasData } );
// ...
if (netStream.DataAvailable)
{
netStream.Read(buffer, 0, 20);
// process buffer
}
}
3 Réponses :
Le moyen le plus simple est probablement d'utiliser un fil supplémentaire qui lit de manière synchrone et met une donnée supplémentaire sur une file d'attente supplémentaire.
Alternativement, vous pouvez utiliser l'IO asynchrone, mais c'est un peu délicat - et vous devez toujours avoir une file d'attente supplémentaire.
Bien que socket ait un SELECT () méthode (et vous pouvez obtenir sur une prise à partir d'un Networkstream ) Je ne le crois pas expose cette fonctionnalité d'une manière qui vous permet de le mélanger avec d'autres types de poignées d'attente.
Vous pouvez utiliser les méthodes asynchrones de la réseelecream et définir un manuelReseTevent dans la méthode endreceive.
while (notDone)
{
WaitHandle.WaitAny(new WaitHandle[] { queue1.HasData, queue2.HasData, netStreamManualResetEvent} );
// ...
if (netStream.DataAvailable)
{
// make the buffer from the AsyncState in the callback method available here
// process buffer
}
}
Si l'hôte distant arrête la connexion et que plus de données sont disponibles, 0 octets seront lus. Pourquoi demandez-vous?
Si vous ne pouvez pas faire de BreveRead, lisez zéro octets, vous commencez à avoir à gérer le tampon de lecture entre la boucle principale et le rappel. C'est totalement faisable mais n'est pas aussi gentil que possible.
Pas nécessairement parce que la mémoire tampon restera intacte (par le flux) jusqu'à ce que vous appeliez à nouveau BegneRead après l'appel à endread dans le rappel, cela signifie que vous pouvez gérer le tampon avec des appels bien placés vers BegayRead et endread, par exemple, ne pas appeler Breadread dans Le rappel l'appelez à nouveau après le code tampon de processus
J'ai découvert que si vous appelez NetworkStream.read code> avec la taille = 0 code>, il bloquera: networkstream.Read(buffer, 0, 0);