Question

C’est peut-être une question idiote, mais les écouteurs d’événements utilisent-ils des cycles de traitement comme un minuteur, ou sont-ils inactifs jusqu’à ce que l’événement soit déclenché?

Est-ce spécifique à une langue ou est-ce que toutes les langues traitent la même chose?

Je veux écrire un petit service qui ne fait rien quand un événement de déconnexion du réseau est déclenché, et je ne veux pas que le service utilise des ressources juste en écoute (autre que la mémoire bien sûr).

Je prévois de faire quelque chose comme ça

using NetworkUtilities;
    ManagementEventWatcher networkAdapterArrivalWatcher = new ManagementEventWatcher("\\root\\wmi","SELECT * FROM MSNdis_NotifyAdapterArrival ");
                    networkAdapterArrivalWatcher.Options.Timeout = new TimeSpan(0,0,5);

    ManagementEventWatcher networkAdapterRemovalWatcher = new ManagementEventWatcher("\\root\\wmi","SELECT * FROM MSNdis_NotifyAdapterRemoval " );
                    networkAdapterRemovalWatcher.Options.Timeout = new TimeSpan(0,0,5);

    ConnectionNotifierHandler handler = new ConnectionNotifierHandler();
                    networkAdapterArrivalWatcher.EventArrived += new EventArrivedEventHandler(handler.Arrived);
                    networkAdapterRemovalWatcher.EventArrived += new EventArrivedEventHandler(handler.Removed);

    //Start watching for events
    networkAdapterArrivalWatcher.Start();
    networkAdapterRemovalWatcher.Start();

    public void Arrived(object sender, EventArrivedEventArgs e)
    {
            using (ManagementBaseObject ev = e.NewEvent)
            {
                //Log the event
            }
    }

    public void Removed(object sender, EventArrivedEventArgs e)
    {
            using (ManagementBaseObject ev = e.NewEvent)
            {
                //Log the event
            }           
    }
Était-ce utile?

La solution

En C #, les événements ne sont que des délégués de fonction (pointeur sur fonction), qui seront appelés "à la demande". et n'utilisera pas de cycle de processeur supplémentaire.

MAIS, si vous faites référence à des événements de surveillance tels que:

  • OnConnecitonPending pour un écouteur de socket.
  • OnWindowMessage pour une application de fenêtre.

Je pense que ceux-ci utilisent un thread pour surveiller leurs événements et, bien sûr, coûteront davantage de temps processeur.

Autres conseils

Les écouteurs d'événement n'utilisent aucun temps processeur jusqu'à ce que l'événement soit réellement déclenché (et que votre gestionnaire d'événement soit appelé).

Il n'y a pas de processus d'arrière-plan impliqué avec un écouteur d'événements.

En règle générale, les écouteurs d'événement conformes à un système intégré d'écoute d'événement n'utilisent pas le temps CPU jusqu'à ce que l'événement soit déclenché. Ce sont plutôt des délégués déclenchés par l'événement. Leur intérêt pour l'événement est noté par le système. C’est le cas, par exemple, chez les délégués de style Objective-C / Cocoa, mais le principe s’applique un peu partout.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top