[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Help-smalltalk] Single-step debugging, Semaphore and thread-scheduling

From: Holger Hans Peter Freyther
Subject: [Help-smalltalk] Single-step debugging, Semaphore and thread-scheduling
Date: Sun, 4 May 2014 12:40:13 +0200
User-agent: Mutt/1.5.23 (2014-03-12)


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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]