RE: [RFC] persistence of schedlock mode

["Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>]

  Did I miss some part of the discussion here?

  I really have the impression that this
patch went in by error in a long series of patches 
from Michael all labeled with '[ob]... white space'
without the patch itself being approved on the main thread. 

 First reset_schedlock went in and generated a 'New ARI warning'
Jan replied to it
http://sourceware.org/ml/gdb-patches/2010-05/msg00320.html

  Then, another commit of the same series
http://sourceware.org/ml/gdb-cvs/2010-05/msg00145.html
added a call to reset_schedlock in infrun.c.
as can be seen in
http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/target.c.diff?cvsroot=src&r
1=1.250&r2=1.251

This lead to a compilation error that Hui 
tried to fix, and Joel added a second patch to cleanup.

  I have no opinion of the validity of the patch itself, 
but the way it got into CVS leaves a strange impression to me.


Pierre Muller
Pascal language support maintainer for GDB



> -----Message d'origine-----
> De?: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] De la part de Michael Snyder
> Envoyé?: Wednesday, May 12, 2010 8:09 PM
> À?: gdb-patches@sourceware.org
> Objet?: [RFC] persistence of schedlock mode
> 
> Bug 11580 points out a problem related to persistence of the
> scheduler locking mode.  If you set the mode to "on" (which
> means that only one thread can run), and then kill and restart
> your program, the mode persists and your program may deadlock.
> 
> I don't think this is a problem for mode "step", and it could
> be argued that mode "on" is "use at your own risk".  However
> I've been thinking about how to resolve it, and this simple
> but intrusive patch is what I come up with.
> 
> Comments?