Single-step debugging, Semaphore and thread-scheduling

Hi,

I looked into dead-locks created by debugging.

  3 negated

and pressing F7 until VisualGST is live-locked. When it is live-locked
the GST Process is looping as during a "dispatch" the "idle" process is
being scheduled which re-enters the event-loop.

I think there is more than one issue at play. The main issue is probably
that VisualGST is being impacted by debugging. E.g. if we debug code that
is registering itself as a to be finalized and we are in the
Semaphore>>#critical: and executed a single-step any other VisualGST code
that needs to register as finalizable will sleep on the Semaphore. This
means that if we execute Glib/Gtk+ callbacks from with-in the dispatch
and then block on a semaphore.. the only runnable process will be the
idle one.. which will trigger the polling. :}

Did I express this clearly enough? The first thing we could change is
to add a version of _gst_nvmsg_send to stop gst_interpret when the running
process is supposed to be switched.

The bigger change is to have VisualGST work on a remote image and have
the agents that implement process, debug control be robust against other
processes being debugged. :}

Any ideas for a short-term fix? I would love to release v3.3 of GST
but the VisualGST debugger is breaking in way too simple ways right
now.

cheers
        holger

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

On Sun, May 04, 2014 at 12:40:13PM +0200, Holger Hans Peter Freyther wrote:

> Any ideas for a short-term fix? I would love to release v3.3 of GST
> but the VisualGST debugger is breaking in way too simple ways right
> now.

VisualGST.GtkDebugger extend [
    debugWith: aBlock [
        <category: 'execute events'>

        TaskQueue uniqueInstance add: [
            self isLastContextSelected ifFalse: [ self stepToSelectedContext ].
            aBlock value.
            debugger suspendedContext ifNotNil: [
                (debugger suspendedContext method = (Object>>#removeToBeFinalized))
                    ifTrue: [debugger finish]].
            self updateContextWidget ]
    ]
]


This would be my proposal. Determine some methods we can not support in
single-step mode and then just skip them. Right now this would be the
addToBeFinalized/removeToBeFinalized as the Glib/Gtk code is using them
internally. Same probably goes for the Transcript>>#critical: if the
rest of the code would go through "self critical:" instead of "semaphore
criticial".

Comments on the work-around?

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk

Il 05/05/2014 02:16, Holger Hans Peter Freyther ha scritto:
With a comment, that looks good.

Paolo

_______________________________________________
help-smalltalk mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-smalltalk