You are but the handler is only looked up when we call vmi_events_listen. The event itself can be put into the ring before we have a handler for it in the ghashtable as long as no vmi_events_listen happens in-between the two, which it can't when we think linearly. With multithreading where we have for example one thread calling vmi_events_listen and another registering the singlestep event, this would be a problem as you pointed out.

On Fri May   3 2013 07:18:36 PM CEST, Matthew Fusaro <notifications@github.com> wrote:

> > @@ -128,6 +131,26 @@ status_t vmi_register_event (vmi_instance_t vmi,
> > }
> > 
> > break;
> > +               case VMI_EVENT_SINGLESTEP:
> > +                       for(;vcpu<vmi->num_vcpus;vcpu++) {
> > +                               if(CHECK_VCPU_SINGLESTEP(event->ss_event, vcpu)) {
> > +                                       if(NULL!=g_hash_table_lookup(vmi->ss_events,
> > &(vcpu))) { +                                               dbprint("An event is already
> > registered on this vcpu: %u\n", vcpu); +                                       } else {
> > +                                               g_hash_table_insert(vmi->ss_events, &(vcpu),
> > event); +                                               if(VMI_SUCCESS ==
> > driver_start_single_step(vmi, event->ss_event)){ +                                       
> >               dbprint("Enabling single step\n"); +                                                     
> > rc = VMI_SUCCESS; +                                               } else { 
> > +                                                       g_hash_table_remove(vmi->ss_events,
> > &(vcpu));
> 
> Sure. libvmi is linear, however, once the call to xen happens, that vm
> is latched and will have the flag injected into the control block. That
> is outside of the execution path of libvmi. The next instruction
> boundary the VM hits and executes will cause an event to be dispatched. 
> I don't want an event to come through, pausing the vcpu of the VM, and
> then not have a handler to take care of the event on the ring. This will
> leave the vcpu in a paused state until the ring is flushed. Am i
> thinking about this incorrectly?
> 
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/bdpayne/libvmi/pull/46/files#r4077470