[Rhythmbox-devel] Re: proper shutdown on ctrl-c and other stuff

[Andreas Bombe <bombe informatik tu-muenchen de>]

[accidentally sent to Colin directly instead of the list, resend]

On Sun, Feb 15, 2004 at 12:31:57AM -0500, Colin Walters wrote:
> On Sat, 2004-02-14 at 22:43, Andreas Bombe wrote:
> > Currently rb seems to have no signal handler to catch SIGINT or
> > anything.  This means that it dies hard when it gets any termination
> > signal without shutting down properly.
> 
> Signals are basically evil, and interact especially poorly with
> multithreaded applications.  
> 
> One nice thing about Rhythmbox being based purely GTK+ and GNOME is that
> in theory we can be portable to other platforms like MacOS and Windows,
> the latter of which doesn't have signals.
> 
> So I'd rather avoid sprinking #ifdefs about the source and the
> portability problems that go with that, just to get a nice shutdown if
> you send SIGINT (which really no normal user should be doing).

a) signal() is ANSI-C and b) if the user starts it from the command line
they may expect a CTRL-C to shut it down cleanly (I certainly did).
Also a "kill $pid" should result in clean shutdown.

Actually the real problem is that the rhythmdb is only saved on clean
shutdown, but I'm working on that now.

> > I can't see an obvious way to shut down or signal to shut down the
> > running RBShell in the proper context.  
> 
> Doing anything nontrivial from a signal handler context is a big pain. 
> It might work if you queued an idle function from the handler, but even
> that is kind of shady if the SIGINT came inside the glib code for
> queueing a signal handler - it would probably just deadlock, since it
> would try to re-acquire the already locked context mutex.
> 
> The safest way to do it would be to set a simple global variable, and
> have an idle function that polls that every 2 seconds or something.

Ok, I hoped there would be some manageable way to set a flag that would
be checked regularly or an easy way to queue some command.  Well, it's
arguable whether abrupt kill on any signal is cleaner. ;-)



> > Also, the sources are riddled with whitespace at end of lines,
> > whitespace only lines and inconsistently mixed spaces/tabs.  Sic an
> > Emacs with develock mode on the sources and have your eyeballs melt.  I
> > suppose fixing that would be very intrusive, resulting in many merge
> > rejects and the like.
> 
> Right...at least the mixture of tabs and spaces I suppose is mostly my
> fault, since I use Emacs (which defaults to that), but I inherited the
> original codebase from a vim user.
> 
> There's really two ways to solve this - tabs only, or spaces only.  If
> we're going to change, I'd like to just use spaces only, since it allows
> for nicer-looking indentation.

I don't know - nicer-looking indentation?  The tabs are set at 8 spaces,
right?  There should be no problem doing it the way Emacs does it by
default (tabs as far as possible then fill with spaces).

The mixed tabs/spaces I referred to were spaces followed by tabs in the
same line.

Is there a line length limit you'd prefer?  The HACKING file mentions
style but no line length.

-- 
Andreas Bombe <bombe@informatik.tu-muenchen.de>    GPG key 0x04880A44