avrdude-dev
[Top][All Lists]
Advanced

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

Re: [avrdude-dev] Cleanup after ^C


From: Joerg Wunsch
Subject: Re: [avrdude-dev] Cleanup after ^C
Date: Sun, 10 Jan 2010 11:08:52 +0100
User-agent: Mutt/1.5.20 (2009-06-14)

As Michal Ludvig wrote:

> one outstanding problem with the BusPirate programmer that should be
> addressed before the next release is the behaviour when avrdude gets
> killed (for instance with Ctrl-C) during programming. That leaves
> the BusPirate in a non-default mode that isn't very easy to get out
> from.

I've got my doubts we'll be able to fix that before the next
release...

> I'd like to prevent that by catching ^C, as that's the most likely cause
> for an unclean exit, and reset BusPirate before avrdude dies. This can
> easily be done in Linux/Unix(/OS-X?) with a custom handler for SIGINT
> signal - is that an acceptable solution?
> 
> How to do something similar on Windows?

I tried adding a signal(SIGINT, ...).  It compiles, but is obviously
not called when hitting ^C.

> And how do the other programmers handle unclean exits? Do we simply
> leave them in a funny state and reset before the next run?

Right, that's the way they currently (don't) handle it, and also the
reason why I doubt we'll be able to hold off a release for that.

There's quite a bit of overall cleanup needed before we can do that.
Things to consider:

. There are still many functions in libavrdude that directly call
  exit(1).  They should not do that.  Instead, they should propagate
  their failure through a return code, and leave it up to the caller
  to handle it.  The only file that should ever call exit(1) is
  main.c.

. We need a per-programmer cleanup hook, that can be invoked as part
  of main.c's cleanup actions right before exiting.  Care has been
  taken that the programmer already arrived in a state where cleaning
  up actually makes sense, as well as de-installing the cleanup
  handler up normally shutting down the programmer.  There might be
  applications in future that want to run more than one programming
  session before really exiting.

. Remember that the amount of actions that may be performed within a
  signal handler is /very/ limited.  For example, you are not allowed
  to perform anything that might invoke malloc/free, and this includes
  things like printf.  Thus, the signal handler basically can only set
  a flag, and has to leave it to the upper layers to perform the right
  actions.  This, in turn, requires a lot of structural cleanup.

Just so nobody gets me wrong: I really appreciate that kind of
feature, as leaving e.g. a JTAG ICE mkII in a half-baked state is a
nuisance.  But don't let us do it by introducing even more crocks,
let's do it right instead.

If it weren't for the sheer amount of existing code, I think rewriting
everything in C++, using exceptions, would be a much cleaner way, but
it's going to take man years to do that I'm afraid.

-- 
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)




reply via email to

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