[Libburn] Re: Handling abort situations with libburn

[scdbackup at gmx.net]

Hi,

have another report from the cdrskin elk test area.

I am pressing Ctrl+C at any imaginable occasion now.
In most cases i get a nicely released drive after
the program has ended.
Now i found another problem with abort situations
(no fear, they all get listed).

If i interrupt  burn_drive_grab()  while it is
gnawing on a freshly loaded media then the drive
is in status  BURN_DRIVE_GRABBING  and refuses
to be released ("Assertion `!d->busy' failed")
as well as the library refuses to be finished
without drive release ("Assertion `d->released' failed").
The drive status does not change from BURN_DRIVE_GRABBING
while the abort handler is waiting for 74 minutes.
A classical Catch 22.

This has nothing to do with the real drive's state.
The real drive is left locked but can be revived by a
simple  eject /dev/sr1  or by a successful cycle of
init-grab-release-finish of another libburn process.
The drive status of the aborting libburn process
does not change by this revival of the real drive.
It seems just to be an inner problem of libburn
being undecided what to do.


My current remedy is to set signal handling to
full ignore during the grab phase. This introduces,
of course, the problems of both: ignorance towards
the external world and the inability to ignore
SIGKILL. The timespan for grab is about 5 seconds
at most so that it is not easy to  ps | grep  and
 kill -9  fast enough. :))

I would prefer to have a call which cleans up a
drive in status BURN_DRIVE_GRABBING gracefully.
But don't feel pushed. I only push for the
re-unification of our two libburns :)) and even
this i do with a ;)


Have a nice day :)

Thomas