On 02/02/2011 04:35 PM, Tom Tromey wrote:
>>>>>> "Sami" == sami wagiaalla<swagiaal@redhat.com>  writes:
>
> Sami>  Hmm... We can just create the corresponding Python object, but
> Sami>  shouldn't this situation be an error condition since
> Sami>  gdbpy_breakpoint_created is observing breakpoint creation and creating
> Sami>  the needed python objects ?
>
> No, because gdbpy_breakpoint_created filters out some breakpoints,
> notably internal ones.
>

Ah, I see. This case now generates a generic stop event as you suggested 
in a comment below.

> Sami>  Yes that is correct. I created a new event type called ThreadEvent
> Sami>  to be a parent to all events which can be thread specific. Stop
> Sami>  events and continue event are now children of thread event.
>
> In this case I think ThreadEvent should be in the docs.
>

Added. I also, documented StopEvent. In events which inherit from others 
I added a statement asking the reader to refer to the parent. Do you 
think that is enough, or should the inherited attributes be restated ?

> Sami>  +PyObject *
> Sami>  +create_breakpoint_event_object (struct bpstats *bs)
> Sami>  +{
> Sami>  +  PyObject *breakpoint = gdbpy_breakpoint_from_bpstats (bs);
> Sami>  +  PyObject *breakpoint_event_obj =
> Sami>  +      create_stop_event_object (&breakpoint_event_object_type);
> Sami>  +  if (!breakpoint_event_obj || !breakpoint)
> Sami>  +    goto fail;
>
> This wouldn't work, since if breakpoint==NULL, we never set an error
> message.
>
> I think this code should probably have a way to cause emit_stop_event to
> fall through to the "unknown" case.
>

Done.

> I didn't see py-threadevent.c in the patch.
>

Added.